我错误地认为我的内部 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]
如果我从外部服务器进行 AB，我会得到大约 180RPS - 与 blitz.io 的结果相同。
我怎么知道这不是故意节流？
如果我从多个外部服务器进行基准测试，所有结果都会变差，这使我相信问题出在我的服务器的出站流量上，而不是我的基准测试服务器/blitz.io 的下载速度问题。
所以我又回到我的结论：我的服务器无法足够快地发送数据。
我说得对吗？还有其他方法可以解释这些数据吗？解决方案/优化是设置多台服务器 + 负载平衡，每台服务器每秒可处理 180 次点击吗？
我对服务器优化还很陌生，因此我很感激任何关于解释这些数据的确认。
出站流量
以下是有关出站带宽的更多信息：网络图显示最大输出为 16 Mb/s：每秒 16 兆比特。听起来一点也不多。
由于有人建议限制，我对此进行了研究，发现 linode 的速度上限为 50mbps（显然我根本无法达到这个上限）。我将其提高到了 100mbps。
由于 linode 限制了我的流量，而我甚至没有达到这个上限，这是否意味着我的服务器确实应该能够输出高达 100mbps 的速度，但受到其他内部瓶颈的限制？我只是不明白如此大规模的网络是如何工作的；它们发送数据的速度真的能和从硬盘读取数据的速度一样快吗？网络管道那大的？
综上所述
1：基于上述内容，我认为我可以通过在多 nginx 服务器设置之上添加一个 nginx 负载均衡器来将我的 180RPS 提高到 LB 后面每个服务器正好 180RPS。
2：如果 linode 有 50/100mbit 的限制而我根本达不到，那么我肯定可以采取一些措施，使用我的单服务器设置达到该限制。如果我可以在本地足够快地读取/传输数据，而 linode 甚至有 50mbit/100mbit 的上限，那么肯定存在一个内部瓶颈，不允许我达到这些上限，而我不确定如何检测。对吗？
我意识到这个问题现在很大而且很模糊，但我不知道如何将其浓缩。对于我得出的任何结论，任何意见都值得赞赏。
答案1
问题在于我假设 linode.com 图表峰值是真实峰值。结果发现图表使用了 5 分钟的平均数据点，因此我的峰值看起来是 24mbits，而实际上我达到了 50mbit 的上限。
现在他们已经将其提高到 100mbits，我的基准测试立即上升到新的出站流量限制。
如果我早点注意到就好了！我的很多推理都基于这样的想法：由于该图表，我没有达到出站流量限制。
现在，我的峰值为每秒 370 个请求，刚好低于 100mbps，此时我开始收到“积压”请求，并且响应时间开始增加。
我现在可以通过缩小页面来增加最大并发量；启用 gzip 后我得到 600RPS。
当我突然达到峰值并且待处理请求的积压（受带宽限制）开始累积时，我仍然会遇到问题，但这听起来像是一个不同的问题。
这是关于优化/读取数据/缩小可能问题范围的一次很好的教训。非常感谢您的意见！
答案2
现在你明白这一点已经有点晚了...但也许你应该考虑时不时地阅读一下 ServerFault 博客。
我特别想到了这篇文章，他们讨论了为什么一秒轮询间隔不会时不时地切断它，这与您所遇到的问题非常相似。
我们发现，在 1 Gbit/s 接口上，我们经常以 10-30 MBit/s 的速率丢弃数据包，这损害了我们的性能。这是因为 10-30 MBit/s 的速率实际上是每 5 分钟传输的位数，转换为一秒的速率。当我们使用 Wireshark 进行深入研究并使用一毫秒 IO 图形时，我们发现所谓的 1 Gbit/s 接口会频繁地突破 1 Mbit/ms 的速率。
当然让我思考了。我知道我会一有机会就把这个方法告诉店里的其他 SA，这样当我们遇到这个问题时，就会显得非常聪明和敏锐。
谁知道呢，我甚至可能会让他们中的一些人知道这个秘密。:)
答案3
它可能受网络限制，但不一定只是带宽问题。远程测试单元的延迟会影响任何给定时间待处理的连接数量（等待 50 毫秒的确认与本地 0.5 毫秒有很大不同），以及连接过程中窗口大小的协商和稳定。您还可能会遇到一定程度的数据包丢失 - 无论是由于拥塞还是由于运营商（或上游运营商）的带宽限制机制。
我建议从公式中尽可能地消除一些因素，以得出合理的基线。测量从您的服务器到一般互联网上的几个点的峰值带宽、延迟和数据包丢失。虽然听起来不太可能，但请尝试搜索“Voip 流量测试”或类似内容。一些 VOIP 服务提供商都有可以以相当高的准确度测量这些类型的模式（双向）的应用程序。一旦您获得了一些关于链接实际可用速度的有效经验数据，那么您的结果就可能得到验证。
除了带宽测试之外，查看低于标准的网络流量的数据包捕获以查找过多的重新传输次数以及测量服务器响应请求的明显时间也可能很有用（如果这个值作为连接数的函数大幅增加，这是一个很大的线索）。