ローカルとリモートでabを実行することの違いは何ですか？
私は自分のサイトをApacheabでベンチマークしていましたが、サーバーでabを実行する場合と、クライアントボックスでabをリモートで実行する場合で、応答時間が大きく異なることに気付きました。
したがって、サーバーでabを実行することと、abをリモートで実行することの最大の違いは何ですか。ネット輸送にかかる時間はありますか？
遅延とネットワーク容量。
Siege（ABと非常によく似ています）を使用した同時実行/負荷テストについて、ローカルテストとリモートテストについて具体的に言及した優れた記事を作成しました。
あなたはここで完全版を読むことができます：
リモートサーバーのテストは、同時実行テスト（つまり、繰り返し満たすことができる要求の数）であるため、ほとんど意味がありません。当面のボトルネックは、2台のマシン間のネットワーク接続です。遅延とTCP/IPオーバーヘッドがリモートサイトのテストを完全に無意味にする原因であり、2つのサーバー間のピア間のわずかなネットワーク輻輳はすぐにパフォーマンスの低下を示します。したがって、実際に機能し始めるのは、TCP 3ウェイハンドシェイクを完了する速度です。テスト対象のサーバーは、動的ページまたは静的0バイトファイルを提供している可能性があります。接続がボトルネックであるため、まったく同じパフォーマンス率を確認してください。
簡単なpingを使用してこれを表示できます。データセンターは英国のマンチェスターにあるため、英国のサーバー、次に米国のサーバーにpingを実行して、違いを示します。両方のサーバーは、100Mビット接続を介してインターネットに接続されています。
英国から英国への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 --- 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 mstime=2.86 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 --- 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トランザクションになるということです。
これをテストしてみましょう…
[~]$ siege http://www.wiredtree.com/images/arrow.gif -c 1 -t 10S -b ** SIEGE 2.66 ** Preparing 1 concurrent users for battle. The server is now under siege... Lifting the server siege...done. Transactions: 50 hits Availability: 100.00 % Elapsed time: 9.89 secs Data transferred: 0.00 MB Response time: 0.20 secs Transaction rate: 5.06 trans/sec Throughput: 0.00 MB/sec Concurrency: 1.00 Successful transactions: 50 Failed transactions: 0 Longest transaction: 0.20 Shortest transaction: 0.196TPSの予測値のすぐ下。しかし残念ながら、これは常に当てはまります。リモートサーバーがはるかに多くの機能を備えている場合でも、遅延は常に同時実行テストを台無しにすることが証明されます。米国のサーバーからまったく同じテストを繰り返して、遅延が実際にテストにどのように影響したかを確認しましょう。最初に簡単な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=52 time=62.8 ms --- www.mediatemple.net ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3067ms rtt min/avg/max/mdev = 62.872/62.922/62.946/0.029 ms [~]$ siege http://mediatemple.net/_images/searchicon.png -c 1 -t 10S -b ** SIEGE 2.72 ** Preparing 1 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 73 hits Availability: 100.00 % Elapsed time: 9.62 secs Data transferred: 0.22 MB Response time: 0.13 secs Transaction rate: 7.59 trans/sec Throughput: 0.02 MB/sec Concurrency: 0.99 Successful transactions: 73 Failed transactions: 0 Longest transaction: 0.14 Shortest transaction: 0.12これで、テストサイトに近いサーバーを使用するだけで、サーバー側の変更なしで1秒あたりのトランザクション数を2倍にすることができました。これは、Siegeがネットワーク遅延にどれほど敏感であるかを示しています。
Siegeは、テストサーバーとリモートサーバーで使用可能な帯域幅によって制限されます。したがって、より高いレベルのスループットに到達し始めると、ダウンロードされるコンテンツの量が増え始めます。上記の例では、0.02MBが10秒でダウンロードされました。これはわずか0.16 Mbps（メガビット/秒）です。ただし、同時ユーザーの数を増やし始めると、状況が根本的に変化する可能性があり、サーバー自体が容量に達するずっと前に、ネットワーク接続が飽和状態になるのは非常に簡単です。
したがって、テスト対象のサーバーに使用可能な帯域幅が20Mビットしかない場合、前述の4Kbリソースで最大約500 req/sが表示される可能性があります。
はい、異なるネットワーク状況が原因です。 HTTPリクエストは、2回のラウンドトリップを必要とする傾向があります（非常に小さなリクエストとレスポンスの場合）。
Client -> Server, SYN
Server -> Client, SYN/ACK
Client -> Server, ACK and HTTP request
Server -> Client, HTTP response
したがって、サーバーにpingを実行し、それを2倍にします。これは、平均して各リクエストに追加される時間です。
-kを使用してHTTPキープアライブを有効にし、それらのラウンドトリップの1つを方程式から外すことができますが、レイテンシーのためにローカルリクエストよりも遅くなります。
あなたが示唆したように、違いはリモートクライアントからウェブサーバーへのインターネット転送によるものです。
したがって、ベンチマークを実行してユーザーエクスペリエンスをシミュレートすることは、常に良い習慣です。だから私は、訪問者の地理的位置に基づいてさまざまなベンチマークを実行して、訪問者がサイトをどのように体験しているかを調べようとしています。たとえば、訪問者のほとんどが米国から来ている場合、そこからEC2インスタンスを実行し、ベンチマークを実行します。
これに基づいて、必要に応じて何らかのCDNを展開することを決定できます。