web-dev-qa-db-ja.com

SiegeとABでのテストはどのくらい正確ですか?

SiegeとABを使用した負荷テストの結果にどれだけ信頼できるか知りたいです。静的アセット(画像、JS、CSS)が考慮されていないことはわかっていますが、すべてがCDNから提供されていると仮定すると、Siege/ABが200人の同時ユーザーに対応できると言った場合、私がすべきではない理由はありますか?信用しませんか?テストを実行しているマシンにある可能性のある制限など、他の要因を考慮していませんか?

22
Matt Fordham

これは、Siegeまたはabタイプのテストを実行しようとする際の落とし穴について説明し、負荷がかかった状態でWebアプリまたはWebサイトがどの程度うまく機能するかを抽象化した非常に優れた記事です。

http://www.sonassi.com/knowledge-base/magento-kb/why-siege-isnt-an-accurate-test-tool-for-magento-performance/

このタイプのテストを行う際の問題を提起する、そのページのいくつかの箇条書きを次に示します。

  • Siegeは、実際のユーザー(または複数のユーザー)が実際にWebサイトで行うことを表すものではありません。生の応答コードとHTMLのみをロードでき、ページ内の他のすべての要素(画像、CSS、JS、またはその他の静的コンテンツ)はロードできません。したがって、効果的には、PHPパフォーマンスのみをテストします。

  • また、セッション/ Cookieのサポートは非​​常に限られており、パイプラインのサポートはなく、HTTP /1.1の基本的なサポートもありません。生成される負荷は実際のユーザーの負荷とはまったく異なりますが、変更後のクイックリファレンスには適しています。実生活でユーザーにとって何かが変わることを実際に示しているわけではありません。

  • Siegeは簡単にだまされて、提供されている静的ファイル(つまり、純粋なHTMLファイル)と動的ファイル(つまり、動的Magento PHPページ)を区別できません。あらゆる種類の静的ファイルプロキシを実行している場合、結果はすぐに歪められます。この時点では、キャッシングプロキシのみをテストし、その背後にある配信速度はテストしません。

  • したがって、Varnish、Nginxキャッシング、mod_pagecacheを使用している場合は、ページをキャッシュに簡単にバッファリングでき、レンダリング時間は20ミリ秒未満になります。 Varnishを使用している場合は、Siegeを使用してパフォーマンスをテストします。まったく同じ結果が得られるため、カテゴリURLではなく画像を読み込んでいる方がよいでしょう。

  • リモートサーバーのテストは、同時実行テスト(つまり、繰り返し満たすことができる要求の数)であるため、ほとんど意味がありません。当面のボトルネックは、2台のマシン間のネットワーク接続です。遅延とTCP/IPオーバーヘッドがリモートサイトのテストを完全に無意味にする原因であり、2つのサーバー間のピア間のわずかなネットワーク輻輳はすぐにパフォーマンスの低下を示します。したがって、実際に機能し始めるのは、TCP 3ウェイハンドシェイクを完了する速度です。テスト対象のサーバーは、動的ページまたは静的0バイトファイルを提供している可能性があります。接続がボトルネックであるため、まったく同じパフォーマンス率を確認してください。

あなたのウェブサイトの全体的なパフォーマンスに最も劇的な影響を与える可能性がある記事で彼らが議論する他の問題はあなたのサイトとそれにアクセスしているクライアントの間の待ち時間です。彼らは、レイテンシーがエンドユーザーに感じられる方法でサイトのパフォーマンスにどのように影響するかについての良い説明を持っていますが、Siegeおよびabタイプのテストツールは決して公開しません。

再び記事を抜粋:

英国から英国へのping

[~]$ ping www.bytemark.co.uk -c4
PING www.bytemark.co.uk (212.110.161.177) 56(84) bytes of data.
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=1 ttl=57 time=2.86 ms
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=2 ttl=57 time=2.51 ms
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=3 ttl=57 time=2.54 ms
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=4 ttl=57 time=2.63 ms
--- www.bytemark.co.uk ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.515/2.641/2.869/0.142 ms

英国から米国へのping

[~]$ ping www.mediatemple.net -c 4
PING www.mediatemple.net (64.207.129.182) 56(84) bytes of data.
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=1 ttl=49 time=158 ms
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=2 ttl=49 time=154 ms
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=3 ttl=49 time=154 ms
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=4 ttl=49 time=154 ms

--- www.mediatemple.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 154.155/155.282/158.321/1.802 ms

パフォーマンスの違いをすぐに確認できます。英国から米国への単一のTCP/IP接続の場合、156ミリ秒かかり、英国のサーバーへの接続の62倍でした。つまり、何かを試す前に、Siegeで1秒間に達成できる最大スループットは、レイテンシーだけのために、1秒あたり約6トランザクションになるということです。

記事全体を読むことを強くお勧めします。 Siegeabなどのツールを使用してパフォーマンステストを行う際の落とし穴を説明するのに非常に役立ちます。

35
slm