2

レポートを実行し、90 秒以内に SQL サーバーに対して約 100 万の SQL クエリを実行する PHP アプリケーションを取得しました。この期間中、誰もこの Web ベースのアプリケーションを使用できません。エッグ タイマーは作動していますが、レポートがタイムアウトするか完了するまで何も読み込まれません。私はこの問題を隔離された環境でテストし、私自身がそこにいて、ブラウザーでレポートを実行しました。その後、他のブラウザー ウィンドウからこのアプリケーション サイトへのすべてのアクションがハングしました。

テスト環境に関する詳細:

Windows 2008 R2 x64 - IIS 7.5 - PHP 5.3.8 via FastCGI 
Windows 2008 R2 x64 - SQL Server 2008 R2 x64

IIS の FastCGI 設定:

Instance MaxRequests = 200
Max Instances = 16
Activity Timeout = 70
Idle Timeout = 300
Queue Length = 1000
Rapid Fails PerMin = 10
Request Timeout = 90

各 SQL 要求は、SQL サーバー側で 60 ミリ秒未満で完了します。Web サーバーと SQL サーバーの両方の CPU 負荷は 10% 未満です。Web サーバーには 16GB の RAM があり、レポートの実行時には約 60% の RAM が使用可能です。

PHP が SQL サーバーに対してあまりにも多くのリクエストを送信し、忙しすぎて他のリクエストを処理できなくなっているようです。この場合、PHP がより多くの同時要求を処理できるように微調整できるものがあるはずです。

誰か知っていますか？助けてください！

4

1 に答える 1

5

ここで暗闇の中で突き刺し、セッションのロックが原因であると想定します.

PHP に付属の標準セッション ハンドラーを使用すると、スクリプトの実行中に (推奨) 書き込みロックを使用して、セッション ファイルが破損しないようにします (session_write_close()以前に呼び出された場合を除く)。

同じセッションにアクセスしようとする他のスクリプト (ブラウザは同じ Cookie 値を渡します) は、ロックが解放されるまで、可能な限り待機します。

これを確認するには、まったく異なる 2 つのブラウザーを使用して 2 人のユーザーをシミュレートします (1 人はレポートを実行し、もう 1 人はサイトにアクセスします)。それが機能する場合は、セッションのロックが原因であると確信しています。

レポートを実行しているときはわかるので、これは問題にはなりませんが、それでも問題が発生する可能性がある場合は、次の 2 つのことを考慮することができます。

  1. レポート スクリプトのセッションを開始しないでください (ただし、権限のないユーザーがレポート スクリプトを実行しようとする可能性もあります)。
  2. session_write_close()ユーザーの身元を確認した後に使用して、面倒な作業が始まる前にセッションを閉じます。
于 2012-09-04T15:46:54.573 に答える