我错误地认为我的内部AB测试意味着我的服务器每秒可以处理1k并发@ 3k点击。

目前，我的理论是网络是瓶颈。服务器无法足够快地发送足够的数据。

来自blitz.io的并发率为1k的外部测试显示，我的命中率上限为180，由于服务器每秒只能返回180，因此页面的响应时间越来越长。

我已经从nginx提供了一个空白文件，并进行了替换：它并发地按1：1比例缩放。

现在要排除IO / memcached瓶颈（nginx通常从memcached中提取），我提供了文件系统中缓存页面的静态版本。

结果与我的原始测试非常相似；我的上限是180 RPS。

将HTML页面分成两半，可使我的RPS翻倍，因此，它肯定受页面大小的限制。

如果从本地服务器内部内部使用ApacheBench，则在高传输速率下，整页和半页上都可以获得大约4k RPS的一致结果。传输速率：接收到62586.14 [Kbytes / sec]

如果我从外部服务器进行注册，我将获得180RPS的收益-与blitz.io结果相同。

我怎么知道这不是故意的节流？

如果我从多个外部服务器进行基准测试，那么所有结果都会变差，这使我相信问题出在我的服务器出站流量，而不是基准服务器/ blitz.io的下载速度问题。

所以我回到我的结论：我的服务器不能足够快地发送数据。

我对吗？还有其他方法可以解释这些数据吗？解决方案/优化是否设置了多个服务器+负载平衡，每个服务器每秒可以处理180次匹配？

我对服务器优化还很陌生，因此感谢您对这些数据进行解释的确认。

出站流量

以下是有关出站带宽的更多信息：网络图显示最大输出为16 Mb / s：每秒16兆位。听起来一点也不。

由于有节流的建议，我对此进行了调查，发现linode的上限为50mbps（显然，我甚至还没有达到这个上限）。我把它提高到了100mbps。

由于linode限制了我的访问量，而我什至没有实现，这是否意味着我的服务器确实应该能够输出高达100mbps的数据，但受到其他内部瓶颈的限制？我只是不了解如此大规模的网络是如何工作的。它们可以像从HDD读取数据一样快速地发送数据吗？网络管道有那么大吗？

结论

1：基于以上所述，我认为我可以通过在多nginx服务器设置之上添加nginx负载平衡器来提高我的180RPS，使LB后的每台服务器恰好为180RPS。

2：如果linode的限制是50 / 100mbit，而我完全没有达到，则必须做一些事情才能通过单服务器设置达到该限制。如果我可以在本地足够快地读取/传输数据，并且linode甚至不愿意设置50mbit / 100mbit的上限，则必须存在一个内部瓶颈，该瓶颈使我无法确定那些不知道如何检测的上限。正确？

我知道这个问题现在很大而且很模糊，但是我不确定如何浓缩。我做出的任何结论都值得您的任何投入。

问题是我假设linode.com图峰是真实的峰。事实证明，该图使用5分钟的平均数据点，因此当我实际上达到50兆位上限时，我的峰值似乎为24mbits。

现在他们将其提高到100mbits，我的基准立即上升到新的出站流量限制。

如果我早点注意到的话！我的很多推理都基于这样一个想法，即由于该图，我没有达到出站流量限制。

现在，我达到了每秒370个请求的峰值，这个速度接近100mbps，这时我开始收到请求的“积压”，响应时间开始增加。

我现在可以通过缩小页面来增加最大的并发性。启用gzip后，我得到600RPS。

当我突然达到峰值并且未决请求的积压（受带宽限制）开始累积时，我仍然遇到问题，但这听起来像是一个不同的问题。

在优化/读取数据/缩小可能出现的问题方面，这是一个很棒的课程。非常感谢您的投入！

现在，您已经弄明白了一点……但是也许您应该考虑不时阅读ServerFault博客。

我特别想起这篇文章，他们在这里讨论为什么有一秒钟的轮询间隔不会时不时地减少，这与您遇到的问题非常相似。

我们发现，我们在1 Gbit / s接口上频繁丢弃数据包的速率仅为10-30 MBit / s，这会损害我们的性能。这是因为10-30 MBit / s速率实际上是每5分钟转换为1秒钟速率的传输位数。当我们深入研究Wireshark并使用一毫秒的IO绘图时，我们看到我们经常会爆破所谓的1 Gbit / s接口的1毫秒每毫秒速率。

当然让我思考。而且我只知道我会在我的店里第一个机会在其他SA上销毁它，当我们遇到这个问题时，它将显得异常聪明和敏锐。

谁知道，我什至可以让其中的一些秘密。:)

它可能受到网络的限制，但不一定只是带宽问题。远程测试单元的延迟将影响在任何给定时间挂起的连接数（等待50ms的确认不同于本地的.5ms），以及随着连接进程协商和稳定窗口大小。由于拥塞或运营商（或上游）运营商的带宽限制机制，您还可能会遭受某种程度的数据包丢失。

我建议尽可能从方程式中消除出来以得出合理的基准。测量从服务器到一般Internet上的几个点的峰值带宽，延迟和数据包丢失。听起来不太可能，请尝试搜索“语音流量测试”或类似内容。VOIP服务的多家提供商提供了可以以相当高的准确性（双向）测量此类模式的应用程序。一旦掌握了有关链接实际有用速度的有效经验数据，就可以很好地验证您的结果。

除了带宽测试以外，查看低于标准的Web流量的数据包捕获以查找过多的重传以及测量服务器响应请求所花费的明显时间（。如果值随着连接数量的增加而显着增加，这是一个很大的线索）。