我正在开发一个 Laravel 网站，该网站将部署到运行 SQL Server 的 Windows Server 2019（IIS），并托管在带有 Plesk 的 VPS 上。
我最近将网站部署到服务器上受密码保护的测试子域，以确保一切正常，并查看在实际服务器上模拟生产环境时的速度如何。一般来说，速度非常令人满意：全页响应时间约为 200-800 毫秒。
然而，如果我有一段时间没有访问该网站（不知道具体多长时间——一个小时肯定够了），那么第一的我对测试站点提出的要求是非常很慢，通常需要 10 秒以上，有时需要 30 秒以上。任何后续请求都非常快速且响应迅速，即使是来自不同网络上的不同设备，因此这不是客户端问题。
在另一个域上，该服务器还托管一个实时生产站点，该站点主要用 Classic ASP（VBScript）编写，但也有部分内容用普通（非框架）PHP 编写，这是不是受此问题影响。对实时站点的所有请求都以类似的速度加载，首次请求不会减慢速度。有一个不同的受密码保护的测试子域，它托管实时站点的副本，这也不会受到影响。当我从我的开发机器（Mac）运行时，我使用服务器上的实时数据库，那里的首次请求也没有延迟，所以这不是数据库问题。
我已确保将应用程序池的启动模式设置为，alwaysRunning至少可以排除启动新工作进程是罪魁祸首。服务器的流量很低，因此答案是这个问题不适用。
这个问题总体上与这个问题，只是我的不是 .NET 应用程序，所以那里给出的两个答案都不适用。我也看到有人提到缓存，但总是与 ASP/.NET 应用程序的即时编译缓存有关，这与 PHP 应用程序也无关。
我真的很想弄清楚什么在这个子域/应用程序上花费了如此长的时间（显然，修复它），但我不知道该怎么做。
所以基本上我的问题有两个：
IIS 中是否有办法“计时”请求并找出请求过程中的瓶颈？
如果不是，我应该考虑哪些可能因素，以找出可能导致这种首次请求延迟的原因？
如果我遗漏了一些重要的服务器详细信息，请告诉我。我不是专业的服务器管理员，而且我对 Windows Server 的了解也只是刚刚开始。
答案1
这是经典的应用程序池启动行为。
您是否确定更改了应用程序池的“空闲超时”设置？
如果没有，它将在 20 分钟不活动后关闭，并且下一个请求将需要更长时间。
或者，你检查过应用程序池的回收设置吗？回收也会导致这个问题。
应用程序池启动模式设置无法解决您的问题。