我们有一台运行Apache2.2的Windows Server 2003机器。 大多数情况下，服务器上没有任何负载，但是我们在3400个PC上有一个通知程序，可以请求一个播放64KB .wav文件的小型网页。 当一个事件发生的时候，那些3400的PC都在3分钟的时间内请求网页。 在一些机器上，我们看到浏览器在绘制页面之前，处于“连接”状态一点点。 发生了什么，我们如何加快速度？
这需要很长的时间，因为您正在对可怜的服务器执行拒绝服务攻击。
如果警报发生在本地，为什么计算机需要从远程服务器获取audio文件？ 他们有没有通知应用程序分发的本地副本？
我会怀疑你需要调整像threadsperchild这样的值到一个更大的值来处理这个负载。 该值控制一次可以处理的最大请求数。
有几个场景清楚地显示了一个优秀的光Web服务器，特别是单线程服务器的优势。 尝试nginx或lighttpd，我敢肯定，可以遵守一个更小的机器。
你有一个固定的客户数量，你可以在一个时间点服务。 每个插槽用于将文件传输到客户端的时间段。 如果您有100个插槽，并且需要networking5秒来传输文件（也许这些计算机在慢速链接，拨号后面），那么您将需要175秒来为所有这些主机提供服务。 你会看看Web服务器，一切都会好起来的 – 没有太多的CPU负载，没有很多的磁盘负载，没有很多的networking负载。 但那些缓慢的客户正在杀死你。
如果你的ThreadLimit是64（ThreadLimit是一个全局限制），那么，iirc，你只能一次提供64个客户端。 这个图需要至less500-1500毫秒来为每个客户端服务，你有一个math问题。
如果您可以在500毫秒内为单个客户端提供服务，那么每秒服务128个客户端，即为服务3500个客户端提供27.3秒。
如果您可以在1.5秒内为单个客户端提供服务，那么每秒42.66个客户端即可提供服务3500个客户端的82秒。
每个客户端2秒钟是54.6秒为3500个客户服务。
根据networking中的延迟，500毫秒可能是合理计算TCP安装时间，请求时间，传输时间等。
我会运行一个testing，看看需要多长时间才能完成一个请求，然后进行math计算，如果每个请求都有相同的服务时间，则需要多长时间才能为每个人提供服务。
您可能需要总共1000个就绪线程才能够在3.5秒内提供该文件。
此外，你可能想看看apache启动线程需要多长时间 – 如果它闲置时只保留30个线程，并且机器空闲直到这一点，那么它必须启动所有这些线程才能启动为他们服务。 确保空闲线程的最小数量很高。
编辑：
嗯，我做了一些testing，看起来你可以预期最长40毫秒的传输时间，像公司networking。 如果为客户服务需要40毫秒，那么每秒1600客户端，不到2秒钟服务3500客户端。
我得到的下一个最好的答案是stream量的高峰正在触发以太网故障。 我们曾经有一台白天可以正常工作的networking服务器，但晚上会变成垃圾。 发现我们的备份在交换机上行链路上触发故障，使整个交换机放慢。 糟糕的自动协商+糟糕的电缆造成了这种情况。