这是否certificate了networking带宽瓶颈？
我错误地认为，我的内部ABtesting意味着我的服务器可以处理1k并发@ 3k点击每秒。
目前我的理论是networking是瓶颈。 服务器无法足够快地发送足够的数据。
来自blitz.io的1k并发性外部testing显示我的命中上限为180，页面花费的时间越来越长，因为服务器每秒只能返回180。
- MySQL复制性能
- 为什么我的rsync与纯粹的cp甚至scp相比如此之慢？
- 实时监控MS Windows服务器及其服务
- 我应该在robots.txt中阻止哪些漫游器和蜘蛛？
- 虚拟化 – 十个1Gbps链路还是一个10Gbps链路？ （性能）
我已经从nginx提供了一个空白文件，并对其进行了修改：它以1：1的并发性进行扩展。
现在为了排除IO / memcached瓶颈（nginx通常从memcached中提取），我从文件系统提供了一个静态版本的caching页面。
结果与我原来的testing非常相似。 我被限制在大约180 RPS。
将HTML页面分成两半，使得RPS翻了一番，所以受到页面大小的限制。
如果我在本地服务器内部使用ApacheBench，那么在全页面和半页面上都能以高传输速率获得大约4k RPS的一致结果。 传输速率：收到62586.14 [千字节/秒]
如果我从外部服务器AB，我得到约180RPS – 与blitz.io结果相同。
我怎么知道这不是故意的节stream？
如果我从多个外部服务器进行基准testing，所有结果都变差，这导致我认为问题出在我的服务器出站stream量，而不是我的基准服务器/ blitz.io下载速度问题。
所以我回到我的结论，我的服务器无法发送足够快的数据。
我对吗？ 还有其他方法来解释这些数据吗？ 是解决scheme/优化设置多个服务器+负载均衡，每个可以每秒180次点击？
我很新的服务器优化，所以我会很感激任何确认解释这些数据。
出站stream量
以下是有关出站带宽的更多信息：networking图显示最大输出速率为16 Mb / s：每秒16兆比特。 听起来不怎么样。
由于有关节stream的build议，我研究了这个，发现林德有一个50mbps的帽子（我甚至没有接近击中，显然）。 我把它提高到100mbps。
由于linode限制了我的stream量，而我甚至没有打它，这是否意味着我的服务器确实应该能够输出高达100mbps，但受到其他一些内部瓶颈的限制？ 我只是不明白这个规模的networking是如何工作的; 他们可以从硬盘上读取数据吗？ networkingpipe道很大吗？
结论是
1：基于上述情况，我想我可以通过在多服务器端安装一个nginx负载平衡器，在每台服务器后面精确的180RPS的LB上增加180RPS。
2：如果林德有一个50 / 100mbit的限制，我根本没有打，我必须做一些事情来达到我的单个服务器设置的限制。 如果我可以在本地快速读取/传输数据，并且林德甚至有麻烦有一个50mbit / 100mbit上限，必须有一个内部的瓶颈，不能让我打这些帽子，我不知道如何检测。 正确？
我意识到这个问题现在是巨大而模糊的，但我不确定如何浓缩它。 任何input都赞赏我所做的任何结论。
问题是我假设linode.com图峰是真正的高峰。 事实certificate，图表使用了5分钟的平均数据点，因此，实际上我打到了50mbit的上限时，我的峰值似乎是24mbits。
现在他们已经把它提高到100mbits，我的基准立即上升到新的出站stream量限制。
如果只有我早点注意到了！ 我的很多推理都是基于这样一个想法，即由于该graphics，我没有达到出站stream量限制。
现在，我以每秒370个请求的速度达到峰值，正好低于100mbps，此时我开始收到请求的“积压”，响应时间开始增加。
我现在可以通过缩小页面来提高最大并发性。 与gzip启用我得到600RPS。
当我突然出现高峰时，我仍然遇到问题，待处理请求的积压（由带宽限制）开始积累，但这听起来像是一个不同的问题。
在优化/阅读这些数据/缩小可能的问题方面，这是一个很好的教训。 非常感谢您的意见！
现在有点晚了，你已经知道了，但也许你应该考虑不时地阅读ServerFault博客。
我特别想到这个post ，他们讨论了为什么有一秒的轮询时间间隔不会不时削减，有关与你有一个非常类似的问题。
我们发现，我们在1 Gbit / s接口上频繁丢弃数据包的速度只有10-30 MBit / s，这会影响我们的性能。 这是因为10-30 MBit / s的速率实际上是每5分钟转换为1秒速率的比特数。 当我们与Wireshark打成一片，并使用了一毫秒的IOgraphics时，我们看到我们会频繁地突发所谓1 Gbit / s接口的每毫秒1 Mbit的速率。
当然让我想。 而且我知道我知道，我第一次得到机会的时候，在我店里的其他SA上，我们遇到了这样的问题。
谁知道，我甚至可以让他们中的一些人隐藏起来。 🙂
它可能受到networking的限制，但不一定只是一个带宽问题。 远程testing单元的延迟将影响在任何给定时间待处理的连接数（等待50ms的确认与本地的.5ms大不相同），以及随着连接的进行协商和稳定窗口大小。 您也可能会遇到一些数据包丢失 – 无论是作为拥塞的一个function，还是作为您的运营商（或上游）带宽限制的机制。
我build议尽可能从等式中去除一个合理的基线。 测量您的服务器的峰值带宽，延迟和数据包丢失到一般互联网上的几个点。 尽可能听起来不太可能，尝试search“VoIPstream量testing”或类似的。 VOIP服务的几个提供商有能够以相当准确的程度（双向）测量这些模式的应用程序。 一旦你有一些有效的经验数据，你的链接的实际有用的速度，那么你的结果可能会得到validation。
除了带宽testing以外，查看子网站stream量的数据包捕获以查找过多的重新传输次数以及测量服务器响应请求的时间（如果这样价值随着连接数量的增加而显着增加，这是一个很大的线索）。