本地运行 ab 和远程运行 ab 有什么区别?

本地运行 ab 和远程运行 ab 有什么区别?

我正在使用 apache ab 对我的网站进行基准测试,我注意到在服务器上运行 ab 与在客户端远程运行 ab 时响应时间有很大差异。

那么在服务器上运行 ab 和远程运行 ab 最大的区别是什么呢?时间消耗在网络传输上吗?

答案1

延迟和网络容量。

我们写了一篇关于使用 Siege(与 AB 非常相似)进行并发/负载测试的好文章,特别提到了本地测试与远程测试。

您可以在此处阅读完整版本:

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

测试远程服务器几乎毫无意义,因为它是一个并发测试(即可以重复满足多少个请求),直接的瓶颈是两台机器之间的网络连接。延迟和 TCP/IP 开销使测试远程站点完全毫无意义,两台服务器之间的对等点之间最轻微的网络拥塞都会立即显示性能下降。因此,真正开始发挥作用的是 TCP 三次握手的完成速度——被测试的服务器可能正在提供动态页面或静态 0 字节文件——您可能会看到完全相同的性能速率,因为连接性是瓶颈。

我们可以使用简单的 ping 来显示这一点。我们的数据中心位于英国曼彻斯特,因此我们将尝试 ping 英国的服务器,然后 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 倍。这意味着,在您尝试任何操作之前,您在 Siege 上一秒钟可以实现的最大吞吐量将约为每秒 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.19

略低于预测的 6 TPS。但不幸的是,情况总是如此。即使远程服务器能够处理更多事务,延迟也总是会毁掉任何并发测试。让我们从美国的服务器重复完全相同的测试,看看延迟对测试的影响有多大。首先快速 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

现在,我们已经成功地将每秒的交易量增加了一倍,而无需进行任何服务器端更改,只需使用更靠近测试站点的服务器即可 - 这表明 Siege 对网络延迟非常敏感。

Siege 将受到可用带宽的限制在您的测试服务器和远程服务器上。因此,一旦您开始达到更高的吞吐量,下载的内容量就会开始增加。在我们上面的例子中,10 秒内下载了 0.02MB——这是一个微小的 0.16 Mbps(兆比特每秒)。但是当您开始增加并发用户数量时,情况可能会发生根本性变化,并且很容易在服务器本身达到其容量之前就使网络连接饱和。

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

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

答案2

是的,不同的网络情况是原因。HTTP 请求往往需要 2 次往返(对于非常小的请求和响应):

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

因此,ping 您的服务器,并将其加倍;这就是平均添加到每个请求的时间。

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

答案3

正如您所说的,差异是由于从远程客户端到网络服务器的互联网传输造成的。

因此,在进行基准测试时,尝试模拟用户体验始终是一种很好的做法。所以我会尝试根据访问者的地理位置运行不同的基准测试,以了解他们对网站的体验。例如,如果我的大多数访问者来自美国,我会从那里运行一个 EC2 实例并运行基准测试。

基于此,您可以决定是否在需要时部署某种 CDN。

相关内容