2

我有一个 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

IIS 中的 FastCGI 设置：

Instance MaxRequests = 200
Max Instances = 16
Activity Timeout = 70
Idle Timeout = 300
Queue Length = 1000
Rapid Fails PerMin = 10
Request Timeout = 90

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

似乎，PHP 已经向 SQL 服务器发出了太多请求，并且变得太忙而无法处理其他请求。如果是这种情况，那么我应该可以进行一些调整以使 PHP 处理更多并发请求。

有人知道吗？请帮忙！

4

1 回答 1

5

我将在这里暗中刺伤并假设这是由于会话锁定。

当您使用 PHP 附带的标准会话处理程序时，它可以确保您的会话文件不会通过在整个脚本执行过程中使用（建议）写入锁而被破坏（除非session_write_close()之前调用过）。

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

您可以通过使用两个完全不同的浏览器来模拟两个用户（一个运行报告，另一个访问站点）来验证这一点。如果这有效，那么您很确定这是由于会话锁定造成的。

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

  1. 不要为报告脚本启动会话（但这也意味着未经授权的用户可能会尝试运行您的报告脚本）
  2. 在您的繁重工作开始之前关闭会话，session_write_close()在您验证用户身份之后使用。
于 2012-09-04T15:46:54.573 回答