Webサーバーベンチマークのベストプラクティス
いくつかの最適化を行って効果があるかどうかを確認する前に、ベンチマークしたいWebサーバーがあります。
ただし、ベンチマークのベストプラクティスは何ですか？
たとえば、同僚から、ネットワークトラフィックの問題を解消するために、ローカルネットワーク上の別のマシンでマシンのベンチマークを行うように言われました。
ただし、最適化によって実際のケースで違いが生じるかどうかを確認したかったので、ベンチマークにオフサイトマシンを使用することを考えていました。
私は、速度の微調整の多くがネットワーク接続の最適化を扱っていると主張していました。たとえば、Apacheでは、KeepAlive値を使用すると、ブラウザは、リソースごとに接続を開いたり閉じたりする代わりに、単一のTCP接続を使用して複数のオブジェクトを要求できます。
テストがローカルネットワーク接続で行われた場合、その微調整はそれほど大きな違いにはなりませんよね？ js/cssを最小化し、HTMLから空白/コメントを削除する場合も同じです。
一方で、ベンチマークが実行されるたびに一貫性が失われるインターネットトラフィックの問題もあります。数値の変化が微調整によるものなのか、それともその間のサーバーの負荷が増加したのか減少したのか、私にはよくわかりません。
誰が正しいですか？ベンチマークのベストプラクティスは何ですか？両方を行う必要がありますか？
tl; dr-ローカルネットワーク/オフサイト/またはその両方のマシンを使用してベンチマークを行う必要がありますか？
これはすべてあなたのサイトに大きく依存します。オフラインとオンサイトの両方のベンチマークを実行しても問題はありません。しかし、何を微調整し、どのようにテストするのですか？
主に静的コンテンツまたはいくつかのveryの単純な動的コンテンツを提供し、それを非常識な速度で提供している場合は、Apacheタイムアウト/カーネルレベルで調整します。理にかなっています。
動的なサイトがある場合、すぐに微調整することは別の獣になります。確かに、これらすべてのApacheおよびカーネルレベルの最適化を行うことは依然として賢明なことですが、それらにだまされたり、煙に映されたりしないでください。
パフォーマンスの調整/テストに関しては、常に最初に最も遅い部分に注意してください。動的サイトの場合、本当のボトルネックは1）データベースまたは2）サイトで実行されているスクリプトである可能性が高いです。
最も遅い部分がデータベースである場合、データベースを高速化する前に、Apacheのパフォーマンスを調整することは意味がありません。それに加えて、適切なキャッシュ手法が整っていることを確認し、可能であれば memcached または同様のものを実行する必要があります。
だから、それはベンチマークと微調整に約whatでした。さて、どのようにベンチマークするのですか？
私は2種類のベンチマークを実行するのが好きです。数値がすでにわかっている場合（たとえば、サイトが刷新されているため、古いサイトからのユニークビジター、ページの読み込み、および同様の統計がわかっている場合）、現在のWebサイトと同様のレートで現実的なベンチマークを実行します。また、同様のレート* 2でベンチマークを行い、将来の成長に少し耐えられるかどうかを確認します。
私が実行するのが好きな他の種類のベンチマークは、サイトを喫煙して燃やすことです。非常に多くの同時リクエストでベンチマークをできるだけ速く実行することで、それを苦しめます。それが耐えられるなら、素晴らしい、耐えられないなら、私は何が限界点であるかを見つけます。
私が好きなツール：ab、siege、JMeter。
継続的に％T（サービス時間）を指定したカスタムログ形式を使用しました。 se形式の％l（識別名）を置き換えました。これは、チューニングのために遅いページを識別するために使用できます。低速回線での大きな応答は、ネットワークの再試行と同様に、誤検知を引き起こす可能性があります。
カスタムログ要約スクリプトを使用して、応答が最も遅く、平均応答時間が長いページを特定しました。これらは最適化の良いターゲットかもしれません。時間の経過とともにレポートを比較すると、今後の問題を特定するのに役立ちます。
クライアント側のツールは、優れたストレスベンチマークを提供し、修正によってサイトが破損していないことを確認できます。本番環境で得られるものと一致しないベンチマークを提供できる要因があります。