サーバーで APC が有効になっている場合、PHP セッションに問題があります。
このアプリは、APC がなくてもうまく機能します。ただし、APC を有効にしたため、サーバーに大きな負荷がかかると、セッションが混乱しているように見えます。つまり、ユーザーが別のユーザーとしてランダムにログオンしています。APC を無効にすると、すべてが正常に戻ります。同じ問題を抱えている人を見つけることができないようですが、関連する問題は次のとおりです (set-cookie は MS ASP にキャッシュされていました): http://msdn.microsoft.com/en-us/magazine/cc163577. aspx#S2
他の誰かが同様の経験をしていますか？何か提案をお勧めできますか？
PS: すべてのセッションは、php.ini のファイルによって処理されます。apache2 も実行しています。
ここでも同様の問題が発生しています。APC は、再現が困難なため、現時点では主な容疑者にすぎません。
Zend Framework とセッション管理を使用しています。理論では、Zend のコードは APC にキャッシュされ、システムに深刻な負荷がかかると、コードは現在の SID ではなく、以前にキャッシュされた SID を使用します。
私たちのセーフガードは、セッション ID をセッション データ内に保存し、セッションが取得されたときに値を比較することです。ID が異なる場合は、セッションを破棄して終了します。
投稿を完了するために、次の 3 つの方法でこの問題を軽減することに成功しました。
1) IP がセッション ID と一致していることを確認し、一致していない場合はユーザーをログアウトするために追加のチェックを行いました。これを使用して、問題が発生する頻度を追跡できます。
2) XCache に切り替えたところ、すぐに混乱したセッション ID の数が減ったことがわかりました。ただし、非常に重い負荷がかかると、問題は再び醜い頭をもたげます。
3) 次に、php 構成 (xcache.size および xcache.var_size) で Xcache のメモリを 2 倍にすると、問題はなくなりました。
したがって、APC または Xcache のメモリ不足が問題であると考えられます。これが恒久的な解決策であるかどうかを確認するのを待っています。
セッション データが保存される前に、カスタム セッション処理オブジェクトが破棄されるという APC で発生する問題があります。問題とは無関係かもしれませんがsession_write_close、通常の PHP シャットダウンの前に を明示的に呼び出すと、問題が修正されます。
あなたの問題は少し違うように聞こえますが、問題が存在することを確認できます。
apc が実際にデータを混同していることを確認してください...これが発生する可能性があると考えられるのは、満杯になってスタックオーバーフローが発生したときだけです。使用状況を確認し、キャッシュ サイズを増やしてください。