ストレステストと実際のブラウジングの間の不一致
私がセットアップしている新しいサーバーは現在のサーバーよりもかなり遅いことに気づき、問題を調査するためにいくつかのストレステスト/ベンチマークを行いました。
しかし、テストの後、私は矛盾した結果を得ています。
マシンの詳細：
CentOS-6.4 (i386)
Apache 2.4.4
PHP 5.4.17
mySQL 5.6.12
8GB RAM
No cache
これはJoomlaサイトです。
注：このマシンは現在、VPN経由でのみアクセスされます（これは速度の低下に関連している可能性があります）
テストを行う前に、httpdとmysqlを再起動しました。
テスト：
ブラウジング：
is遅い（feelsだけでなく、どのブラウザタイプ（Safari、Firefox、Chrome、IE）でも、ブラウジングすると実際に遅くなります。時間を計りませんでした。ただし、現在のサイトよりも遅く、他のユーザーがいない場合）。
Joomla：を介してデバッグ：
ホームページのデバッグをオンにしましたが、現在のサーバーでテストしているのに対し（そのデバッグのログを介して）レンダリングには平均1.294秒かかります（同じ構成ですが、CentOS6.3とPHP = 5.3）平均0.762秒かかります。
ab：
私は5人のユーザーを同時に試し、1000のリクエストを実行しました。これは、別のマシンから実行されました。
静的テキストファイルまたは単純なエコーea PHP）の場合、これが得られたため、私はこれに本当に苦労しました。
Connection Times (ms) min mean[+/-sd] median max Connect: 3 5 1.7 5 17 Processing: 4 7 1.5 6 20 Waiting: 4 6 1.5 6 19 Total: 8 11 2.5 11 27そしてJoomlaのホームページ：
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.3 0 9 Processing: 321 423 115.8 403 1737 Waiting: 309 406 114.0 386 1706 Total: 322 423 115.9 403 1737とにかく、これは私がブラウジングしたときの1秒以上（テスト1）よりも高速です。
jmeter（2.9）:
5人の同時ユーザーでテストを行い、2秒のランプアップで100回のリクエストを実行しました。
静的ページは私にこの平均を与えました：
label # Samples Average Median 90% Line Min Max Error % Throughoutput KB/sec TOTAL 500 8 8 11 7 21 0.0 92.66123054114159 36.55051195329874そしてホームページは私にこれを与えました：
label # Samples Average Median 90% Line Min Max Error % Throughoutput KB/sec TOTAL 500 445 436 507 366 969 0.0 10.331645831180907 856.8125096859179
最後に、質問：
ストレステスト（abまたはjmeterのいずれか）ではるかに高速な結果が得られたのに、ブラウジングが非常に遅いのはなぜですか？（このテストは適切ですか、それとも他の方法を試す必要がありますか？ ）
（ここでVPNに障害があるかどうかはわかりませんが、ブラウジング速度とテスト速度の説明はありません。どちらもVPNに接続する必要があります）。
I 疑わしい答えはブラウザが行うことであり、jmeterとabはそうではありません。
つまり、Cookieとjavascript（およびある程度の画像）です。
同様に、あなたのベンチマークは実際のブラウジングを実際に表していないと私は主張します。
サイトにアクセスしても、ホームページにアクセスしてページを何度もリロードすることはありません。私は行って、たくさんの異なるものをクリックします。ここでの重要な違いは、サーバーが正しく設定されている場合、生成されたPHPオペコード、生成されたページフラグメントなどの多くがメモリに格納されるため、最初のヒットは遅くなりますが、後続のヒットはすべて速い。
「現実世界」のブラウジングをシミュレートする方法を見つけてみてください。私の頭から離れたアイデアの1つは、Selenium IDEを実行し、ブラウジング中にキーストロークとクリックを記録してから、複数のホスト間でそれらを何度も再生できるようにすることです。
VPNが原因である可能性がありますが、理論的には、両方のタイプの接続でより大きなオーバーヘッドが発生するはずです。両方ともab etal。とブラウザ。
tcpdumpを実行するときに、サーバーでwireshark/ngrep/abなどを実行すると、ブラウザーで同じことを行う場合に比べて、読み込まれるページアセットがはるかに少ないことがわかります。
トムが言ったように、実際のブラウザの動作をシミュレートする必要があります。 JMeterの場合、それは非常に簡単です。
- 追加 HTTP Cookie Manager
- 追加 HTTPキャッシュマネージャー
- HTTPヘッダーマネージャーを追加し、普段使用しているブラウザーのユーザーエージェントを設定します。
- オプションタスクチェック設定のHTTPリクエストまたはHTTPリクエストのデフォルト：HTMLファイルからすべての埋め込みリソースを取得して、埋め込みリソース（gif、css、jsなど）を取得するブラウザーをシミュレートします。
- オプションタスクチェック設定で同時プールを使用します。サイズ：n。 2〜4スレッドを使用します。
「YSLOW」のようなツールでページをチェックしてください。タイムラグが始まる場所のヒントが得られる場合があります。
ボトルネックがデータベースであるかどうかを評価するには、常にmysqlのslow_queriesをチェックし、調整スクリプトを使用します。そうでない場合->（すでに行っています）単純な静的ファイルを使用してWebサーバーのパフォーマンスを確認します。その後、abで;次に、ブラウザといくつかのウェブマスタープラグインを使用してページ全体を調査します。