php并发请求卡住?

use*_*590 2 php performance fastcgi

我有一个运行报告的PHP应用程序,并在90秒内向SQL服务器发出大约100万个SQL查询.在此期间,没有其他人可以使用这个基于Web的应用程序 - 鸡蛋计时器正在滚动,但在报告超时或完成之前没有任何内容加载.我在一个孤立的环境中测试了这个问题,只有我自己在那里,在浏览器中运行报告,然后从其他浏览器窗口到此应用程序站点的任何操作都挂起.

有关测试环境的一些细节:

Windows 2008 R2 x64 - IIS 7.5 - PHP 5.3.8 via FastCGI 
Windows 2008 R2 x64 - SQL Server 2008 R2 x64
Run Code Online (Sandbox Code Playgroud)

IIS中的FastCGI设置:

Instance MaxRequests = 200
Max Instances = 16
Activity Timeout = 70
Idle Timeout = 300
Queue Length = 1000
Rapid Fails PerMin = 10
Request Timeout = 90
Run Code Online (Sandbox Code Playgroud)

每个SQL请求在SQL服务器端完成不到60毫秒.Web服务器和SQL服务器的CPU负载均小于10%.运行报告时,Web服务器具有16GB RAM,大约60%的RAM可用.

看起来,PHP已经向SQL服务器发出了太多请求,并且变得太忙而无法处理其他请求.如果是这种情况,那么应该有一些我可以调整以使PHP处理更多并发请求的东西.

有人知道吗?请帮忙!

Ja͢*_*͢ck 5

我只是在黑暗中刺伤并假设它是由于会话锁定.

当您使用PHP附带的标准会话处理程序时,它确保在脚本执行过程中使用(建议)写锁定不会损坏您的会话文件(除非session_write_close()之前调用).

尝试访问同一会话的其他脚本(您的浏览器将传递相同的cookie值)将等待锁定被释放,只要它需要.

您可以使用两个完全不同的浏览器来验证这一点,以模拟两个用户(一个运行报告,另一个访问站点).如果可行的话,你很确定它是由于会话锁定造成的.

这应该不是问题,因为您将知道何时运行报告,但如果这可能会导致问题,您可以考虑两件事:

  1. 不要为报告脚本启动会话(但这也意味着未经授权的用户可能会尝试运行您的报告脚本)
  2. 在您的咕噜声工作开始之前关闭会话,在session_write_close()验证用户身份后使用.