質問編集履歴
2
-
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -1,57 +1,1 @@
|
|
|
1
|
-
|
|
2
|
-
JavaからPHPで動作するものに変更しました。
|
|
3
|
-
|
|
4
|
-
移行後、ある現象について報告があったのですが
|
|
5
|
-
なかなか再現せず何かヒントになる要因が探せないかと投稿しました。
|
|
6
|
-
|
|
7
|
-
＜前提＞
|
|
8
|
-
・PHPのバージョンではphpファイルでなく、デザインもプログラムもhtmlの拡張子を使っている
|
|
9
|
-
・サイトはロードバランサを使用している
|
|
10
|
-
|
|
11
|
-
＜現象＞
|
|
12
|
-
サイト内で何かエラーになる要因が発生した場合、エラーコードを発行し、セッションに格納してエラーページに飛びセッションからエラーコードを取得・表示するがエラーコードが０（エラーコードが０のものはない）と表示されている。
|
|
13
|
-
|
|
14
|
-
＜現状分かっていること＞
|
|
15
|
-
①サイト内のページでエラーが発生した場合、共通関数をまとめて置いているCommon.phpファイルからエラーページに飛ぶ関数を呼び出し、エラーページ（Error.html）へアクセスする。
|
|
16
|
-
|
|
17
|
-
②ページごとに初期化処理があり、その初期化はCommon.phpファイルから呼び出している。この処理の中でもエラー要因があった場合、同ファイルのエラーページに飛ぶ関数を呼び出し、エラーページ（Error.html）へアクセスする。
|
|
18
|
-
|
|
19
|
-
③ ①②ともにエラーコードをセッションに格納する前には必ず、session_start関数を呼んでいる。
|
|
20
|
-
|
|
21
|
-
④ ①②のエラーページに飛ぶ際にはheader関数を使用しており、直後にexit関数を呼んでいる。
|
|
22
|
-
|
|
23
|
-
⑤エラーページには初期化処理は入っておらず、session_start関数を呼んでいる。
|
|
24
|
-
|
|
25
|
-
⑥エラーページのPHPプログラム側でエラーコードのセッションを取得するが、もしエラーコードを格納したセッションがない場合は0を設定するようにしている。
|
|
26
|
-
|
|
27
|
-
⑦この現象についてキャッシュをクリアすることで解消できると報告がある。
|
|
28
|
-
|
|
29
|
-
最初は⑥からセッションがどこかで途切れているため0が入ったものだと予想したのですが、セッションが途切れた場合、エラーページ以外の初期化処理で別のセッションの値をチェックしている箇所があり、存在しない場合、別のエラーコードを発行してエラーページに移動するため、0になることはなさそうです。
|
|
30
|
-
|
|
31
|
-
また、再現の調査を進めていくうちにPHP側のプログラムでよくあるセッションが切れてしまう要因についてあてはまるものがないことやプログラムの途中でセッションが途切れるような処理はどこにも見受けられないと思われ、プログラムが原因でなく、サイトの環境的な問題なのではないかと思い始めました。ただ、調査の範囲が広く、どこから見ていくべきかが不明な状態です。上記の少ない情報だけで要因が絞れるのかわからないのですが調査から数日経過してしまっています・・・。
|
|
32
|
-
|
|
33
|
-
何かご存じの方がいましたらご教授いただけないでしょうか。
|
|
34
|
-
|
|
35
|
-
よろしくお願いします。
|
|
36
|
-
|
|
37
|
-
＜追記1＞
|
|
38
|
-
回答頂きましてありがとうございます。現状で分かっていることを追記します。
|
|
39
|
-
|
|
40
|
-
・このサイトはhtml拡張子でphpプログラムが動作するように設定を行っている。
|
|
41
|
-
・サイトの構成としてはロードバランサ、およびAPサーバ3台を使用している。
|
|
42
|
-
また、ロードバランサの振り分けはラウンドロビン方式になっている。
|
|
43
|
-
・php.iniからセッションはファイルで保持していることが分かった。
|
|
44
|
-
session.save_handler = files
|
|
45
|
-
|
|
46
|
-
・php.iniからセッションの有効時間は1440秒（デフォルト？）であった
|
|
47
|
-
session.gc_maxlifetime = 1440
|
|
48
|
-
|
|
49
|
-
・また、gcを起動させる設定値もデフォルト？であった
|
|
50
|
-
session.gc_divisor = 1000
|
|
51
|
-
session.gc_probability = 1
|
|
52
|
-
|
|
53
|
-
・ロードバランサの仕様については不明
|
|
54
|
-
・Javaで動いていたときはサーバにnginxを入れており、今回のアップデートでapacheにした。
|
|
55
|
-
・上記サイトは現場で作業しているものですが現場内のある人が今回の現象については今までjavaで動いていた
|
|
56
|
-
ものをPHPに変えることでアクセスしてきた人がnginxからapacheに変わりセッションが一時的に上手く作られなかったのでは？という予想話をしていた。
|
|
57
|
-
→インフラ系の知識に乏しく、日本語、内容的に正しいのか不明です。
|
|
1
|
+
--------------------------------------------------------------
|
1
情報の追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -9,15 +9,12 @@
|
|
|
9
9
|
・サイトはロードバランサを使用している
|
|
10
10
|
|
|
11
11
|
＜現象＞
|
|
12
|
-
サイト内で何かエラーになる要因が発生した場合、エラーコードを発行し、セッションに格納してエラーページに
|
|
13
|
-
飛びセッションからエラーコードを取得・表示するがエラーコードが０（エラーコードが０のものはない）と表示されている。
|
|
12
|
+
サイト内で何かエラーになる要因が発生した場合、エラーコードを発行し、セッションに格納してエラーページに飛びセッションからエラーコードを取得・表示するがエラーコードが０（エラーコードが０のものはない）と表示されている。
|
|
14
13
|
|
|
15
14
|
＜現状分かっていること＞
|
|
16
|
-
①サイト内のページでエラーが発生した場合、共通関数をまとめて置いているCommon.phpファイルからエラーページに
|
|
15
|
+
①サイト内のページでエラーが発生した場合、共通関数をまとめて置いているCommon.phpファイルからエラーページに飛ぶ関数を呼び出し、エラーページ（Error.html）へアクセスする。
|
|
17
|
-
飛ぶ関数を呼び出し、エラーページ（Error.html）へアクセスする。
|
|
18
16
|
|
|
19
|
-
②ページごとに初期化処理があり、その初期化はCommon.phpファイルから呼び出している。この処理の中でも
|
|
20
|
-
エラー要因があった場合、同ファイルのエラーページに飛ぶ関数を呼び出し、エラーページ（Error.html）へアクセスする。
|
|
17
|
+
②ページごとに初期化処理があり、その初期化はCommon.phpファイルから呼び出している。この処理の中でもエラー要因があった場合、同ファイルのエラーページに飛ぶ関数を呼び出し、エラーページ（Error.html）へアクセスする。
|
|
21
18
|
|
|
22
19
|
③ ①②ともにエラーコードをセッションに格納する前には必ず、session_start関数を呼んでいる。
|
|
23
20
|
|
|
@@ -29,14 +26,32 @@
|
|
|
29
26
|
|
|
30
27
|
⑦この現象についてキャッシュをクリアすることで解消できると報告がある。
|
|
31
28
|
|
|
32
|
-
最初は⑥からセッションがどこかで途切れているため0が入ったものだと予想したのですが、セッションが
|
|
33
|
-
途切れた場合、エラーページ以外の初期化処理で別のセッションの値をチェックしている箇所があり、
|
|
34
|
-
存在しない場合、別のエラーコードを発行してエラーページに移動するため、0になることはなさそうです。
|
|
29
|
+
最初は⑥からセッションがどこかで途切れているため0が入ったものだと予想したのですが、セッションが途切れた場合、エラーページ以外の初期化処理で別のセッションの値をチェックしている箇所があり、存在しない場合、別のエラーコードを発行してエラーページに移動するため、0になることはなさそうです。
|
|
35
30
|
|
|
36
|
-
また、再現の調査を進めていくうちにPHP側のプログラムでよくあるセッションが切れてしまう要因についてあてはまるものがないことや
|
|
37
|
-
プログラムの途中でセッションが途切れるような処理はどこにも見受けられないと思われ、プログラムが
|
|
38
|
-
原因でなく、サイトの環境的な問題なのではないかと思い始めました。ただ、調査の範囲が広く、どこから見ていくべきかが不明な状態です。上記の少ない情報だけで要因が絞れるのかわからないのですが調査から数日経過してしまっています・・・。
|
|
31
|
+
また、再現の調査を進めていくうちにPHP側のプログラムでよくあるセッションが切れてしまう要因についてあてはまるものがないことやプログラムの途中でセッションが途切れるような処理はどこにも見受けられないと思われ、プログラムが原因でなく、サイトの環境的な問題なのではないかと思い始めました。ただ、調査の範囲が広く、どこから見ていくべきかが不明な状態です。上記の少ない情報だけで要因が絞れるのかわからないのですが調査から数日経過してしまっています・・・。
|
|
39
32
|
|
|
40
33
|
何かご存じの方がいましたらご教授いただけないでしょうか。
|
|
41
34
|
|
|
42
|
-
よろしくお願いします。
|
|
35
|
+
よろしくお願いします。
|
|
36
|
+
|
|
37
|
+
＜追記1＞
|
|
38
|
+
回答頂きましてありがとうございます。現状で分かっていることを追記します。
|
|
39
|
+
|
|
40
|
+
・このサイトはhtml拡張子でphpプログラムが動作するように設定を行っている。
|
|
41
|
+
・サイトの構成としてはロードバランサ、およびAPサーバ3台を使用している。
|
|
42
|
+
また、ロードバランサの振り分けはラウンドロビン方式になっている。
|
|
43
|
+
・php.iniからセッションはファイルで保持していることが分かった。
|
|
44
|
+
session.save_handler = files
|
|
45
|
+
|
|
46
|
+
・php.iniからセッションの有効時間は1440秒（デフォルト？）であった
|
|
47
|
+
session.gc_maxlifetime = 1440
|
|
48
|
+
|
|
49
|
+
・また、gcを起動させる設定値もデフォルト？であった
|
|
50
|
+
session.gc_divisor = 1000
|
|
51
|
+
session.gc_probability = 1
|
|
52
|
+
|
|
53
|
+
・ロードバランサの仕様については不明
|
|
54
|
+
・Javaで動いていたときはサーバにnginxを入れており、今回のアップデートでapacheにした。
|
|
55
|
+
・上記サイトは現場で作業しているものですが現場内のある人が今回の現象については今までjavaで動いていた
|
|
56
|
+
ものをPHPに変えることでアクセスしてきた人がnginxからapacheに変わりセッションが一時的に上手く作られなかったのでは？という予想話をしていた。
|
|
57
|
+
→インフラ系の知識に乏しく、日本語、内容的に正しいのか不明です。
|