在本地和远程运行ab有什么不同？

延迟和networking容量。

我们用Siege写了一篇关于并发/负载testing的好文章（与AB非常相似），特别提到了本地testing和远程testing。

你可以在这里阅读完整版本：

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

testing远程服务器几乎是毫无意义的，因为它是一个并发testing（即可以反复满足多less个请求），直接的瓶颈是两台机器之间的networking连接。 延迟和TCP / IP开销是使远程站点testing完全没有意义的，两台服务器之间的对等networking中最轻微的networking拥塞将立即显示性能下降。 所以真正开始发挥作用的是TCP三次握手的完成速度 – 正在testing的服务器可能是服务于一个dynamic页面或静态的0字节文件 – 你可以看到完全相同的性能率，连通性是瓶颈。

我们可以使用简单的ping来显示。 我们的数据中心位于英国曼彻斯特，因此我们将尝试在英国服务器，然后在美国服务器，并显示差异化。 两台服务器都通过100Mbit连接连接到互联网。

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倍。 这意味着在你尝试任何事情之前，你可以在一秒钟内完成的最大吞吐量将是每秒大约6个事务，因为只有延迟。

让我们把这个testing然后…

 [~]$ 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.19 

就在6 TPS的预测数字之下。 但不幸的是，情况总是如此。 即使远程服务器能够处理更多的事务，延迟也总是会破坏任何并发性testing。 让我们从美国的服务器重复完全相同的testing，看看延迟如何影响testing。 先快速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 

所以你有了它，我们设法每秒处理双倍的事务，而不用简单地使用靠近testing站点的服务器进行任何服务器端更改 – 显示Siege对networking延迟的敏感程度。

攻城将受到testing服务器和远程服务器上可用带宽的限制 。 所以一旦你开始达到更高的吞吐量水平，被下载的内容的数量开始增加。 在我们上面的例子中，在10秒内下载了0.02MB，这是一个很小的0.16 Mbps（兆比特每秒）。 但是，当你开始增加并发用户的数量时，情况就会发生根本性的变化，并且在服务器本身已经达到容量之前很容易饱和networking连接。

因此，如果您正在testing的服务器只有20Mb的可用带宽，那么您可能会在前面提到的4Kb资源上看到最多约500个请求/秒。

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

是的，不同的networking情况是原因。 一个HTTP请求往往需要2次往返（对于一个非常小的请求和响应）：

 Client -> Server, SYN Server -> Client, SYN/ACK Client -> Server, ACK and HTTP request Server -> Client, HTTP response 

所以，ping你的服务器，并加倍; 那就是平均每个请求添加的时间。

您可以使用-k启用HTTP保持活动并从等式中删除其中一个往返，但由于延迟，它仍然会比本地请求慢。

正如你所build议的，不同的是由于从远程客户端到networking服务器的互联网传输。

因此，在进行基准testing时，尝试模拟用户体验总是一个很好的做法。 所以我做了什么，我尝试根据我的访问者地理位置来运行不同的基准，以了解他们如何体验网站。 例如，如果我的大部分访问者来自美国，我会从那里运行一个EC2实例并运行基准testing。

基于此，如果需要，您可以决定部署某种types的CDN。