我在 Windows Server 2016 上使用 IIS，在两台几乎相同的服务器上使用 MySQL 和 PHP。我最近注意到我的两台服务器中的一台速度变慢了，但只有当我的网站尝试同时执行多个脚本实例时才会发生这种情况。它们似乎互相卡住了。
我的搜索页面就是一个完美的例子。当用户输入搜索查询时，每次按下键盘上的键（第二个字母后）都会执行一次搜索，只要距离上次按键至少有 200 毫秒的延迟。因此，如果您打字速度很快，它只会在最后进行一次搜索，但对于打字速度较慢的人（每次按键之间等待超过 200 毫秒的人），这将触发对搜索结果的多次调用。请参阅此屏幕截图。
糟糕的服务器
注意所有待处理的请求，在此屏幕截图中，第一个请求在 19.08 秒内完成。显然太长了。当它们全部完成时，它们都花了超过 15 秒的时间才返回一个简单的结果集。
糟糕的服务器
请记住，这些查询在 MySQL Workbench 中运行以及在我其他没有此问题的服务器上运行时只需几分之一秒。请看此屏幕截图（来自良好的服务器），完全相同的搜索在四分之一秒内返回。
好服务器
在我看来（在糟糕的服务器上）它们无法同时执行，因为某些原因，如果我只执行一次搜索（通过快速输入以触发一次搜索），它会很快返回，但如果我像这样执行多次搜索，它们都会像交通堵塞一样卡住。这是什么原因造成的？
下面的屏幕截图显示了如果我在坏服务器上仅触发一次搜索的结果。如您所见，它返回速度非常快。因此问题仅在同时执行多个相同脚本时出现。
糟糕的服务器
我最近确实对坏服务器做了一些改变，但据我所记得，我做的唯一改变是允许上传更大的文件。
- 在 PHP 中我增加了 post_max_size = 500M
- 在 PHP 中我增加了 upload_max_filesize = 500M
- 在 IIS 中，我将 UploadReadAheadSize 增加到 49152000
- 在 IIS 中，我将允许的最大内容长度增加到 300000000
我可能对此服务器做了其他我不记得的更改。
临时修复
我可以通过在搜索时增加按键之间的延迟来缓解此问题，我已经这样做了，将其增加到 800 毫秒，因此即使打字速度慢的人也不会看到此问题，但这只是一个权宜之计，并不能解决也会影响我的网站其他区域的根本问题。
我尝试过的方法
到目前为止，我已经确认我的 IIS 配置、MySQL 配置 (my.ini) 和 PHP 配置 (php.ini) 在两台服务器上的所有重要方面都是相同的（至少在我看来是相同的）。我还确认，如果我在 MySQL Workbench 中执行此搜索中运行的选择语句，它们在两台服务器上的性能同样好。只有在我的 Web 应用程序中我才会遇到这个问题。
为了以防万一，我暂时撤消了对 IIS 所做的两项更改以便上传更大的文件，但这似乎没有什么区别。
我还下载并安装了 LeanSentry，它每天会警告我一两次，我的网站有被阻止的请求，我想这正是我在这里看到的，但不幸的是，LeanSentry 只能查明 ASP 页面的问题根源，而不能查明 PHP 页面的问题根源。所以它实际上只能确认存在问题，但除此之外它无法帮助我。
其他症状
如果我同时打开多个报告，也会遇到类似的问题。如果我允许一个报告加载完毕后再打开下一个报告，它们都会快速加载，但如果我强制我的应用同时打开多个报告，它们都会卡住。
什么原因可能导致这个瓶颈问题？
答案1
我认为这不是 IIS 服务器的问题，您搜索的每件事都在代码中请求新的调用，而且看起来就像 PHP 脚本中的某些内容需要很长时间。
每次发送新请求时，您只是阻止了新的 PHP 实例，而当 PHP 耗尽实例时它就会崩溃。
很难知道您在搜索 PHP 文件中执行了什么操作，但我认为您正在调用某个 SQL 服务器或某个东西进行搜索。您可以尝试在代码中注释掉搜索查询并进行相同的测试吗？
现在我只是尽我所能猜测，这听起来就像您在 SQL 数据库中使用正则表达式或类似函数，并且当您有很多行时，调用速度会非常慢，这就是它经常挂起的原因。
但是我再次猜测这么晚我才能知道我让你做的测试的结果。
答案2
原来是 HTML 渲染导致了挂起。当我的搜索结果很长时，浏览器需要很长时间才能渲染所有 HTML，而渲染期间它无法处理下一个请求。
我通过将搜索结果限制为 50 行解决了这个问题，因此现在 HTML 几乎可以立即呈现，并且下一个请求可以执行。因此，阻止请求的不是 IIS，而是浏览器。