听起来像是拥塞问题。
如果下一个请求在前一个请求的执行时间内完成,那么您的脚本/页面处理速度有多快并不重要:
它将使用资源(cpu、ram、磁盘、网络流量和连接)。
并让与之平行的一切变慢。
您可以做很多事情,但您需要弄清楚您的设置到底存在什么问题,并确定该措施是否产生了预期的结果。
如果核心问题是资源被并行进程占用,您可以降低连接限制,让更多连接进入等待模式,这样可以保留更多资源用于实际分发页面,而不是让所有内容更加拥塞。
看看这个:
http://oxpedia.org/wiki/index.php?title=Tune_apache2_for_more_concurrent_connections
如果服务器更快地接受连接然后它可以处理它们,那么无论您更改哪个都会遇到问题。它应该在某个时候开始断开连接。如果你更快地将法式长棍面包塞进它的喉咙,让它张开嘴,不管怎样它都会窒息。
如果系统在网络方面不堪重负(传输速度限制、操作系统的最大可能并发连接数等),那么您应该考虑使用负载平衡器。只有在负载均衡器确认服务器有能力实际处理页面请求后,它才会进一步发送给用户。
当您执行任何会减慢页面加载速度的处理(服务器端代码执行、大量数据等)时,这通常很有效。
优化性能
有很多方法可以在网络服务器上执行 PHP 代码,我假设您使用 appache。我不是专家,但有 CGI 和 FastCGI 等模式。这可以大大提高执行速度。调整与这些相关的设置也可以向您展示正在发生的事情。例如,您可能使用少量 PHP 威胁来处理该数量的并发连接。
例如,看看这样的东西
http://blog.layershift.com/which-php-mode-apache-vs-cgi-vs-fastcgi/
这里没有“最适合所有人”的解决方案。要解决它,您需要弄清楚服务器的瓶颈是什么。并采取相应的行动。
每分钟 12000 次呼叫 == 每秒 200 次呼叫。
您可以将测试用例限制在这 200 个中的多个,并在更改设置时增加/减少它。您的目标是在尽可能短的时间内处理该数量的请求,从而确保永远不会发生拥塞。
也就是说:后果。
当您要实施更改以优化您想要达到的最大页面加载次数时,您会无意中引入其他条件。例如,如果 Apache 的最大 ram 使用量会成为问题,那么提高该限制将确保更好的性能,但会增加操作系统在其他进程也想要申请更多内存时耗尽内存的机会。
添加负载平衡器会增加另一个可能的故障层和可能的减速。是的,您可以防止拥塞,但是由于重新路由而导致的减速值得吗?
提高性能会增加系统的负载,从而可以接受更多的并发连接。所以沿着这条线的某个地方会弹出一个不同的瓶颈。不同进程上的高流量总是以所述进程崩溃而告终。 Apache 是一个构建良好的 Web 服务器,因此理论上它应该可以保护您免受上述问题的影响,但是错误地调整设置仍然可能导致崩溃。
因此,在实际使用之前,请小心试验和测试。