经典 ASP：响应时间周期性地极度减慢
Classic ASP: response time periodically slows down extremely
我有一堆（大约 50 个）经典 ASP-Sites on Win2012R2 with Access-Databases，这让我们抓狂。
此服务器上所有站点的所有 asp-页面 运行 平稳运行大约 45 秒，在此期间之后，它们（全部）完全停止响应任何点击 15 到 20 秒，然后这种延迟在接下来的 45 秒内再次消失，就像它以前从未存在过一样，它再次出现 - 依此类推。这个效果是几周前从无到有，经过几个月没有任何问题。
静态 HTML- 页面不受影响，而且看起来，即使 asp- 页面没有连接到他们的数据库 运行 也很好。因此，我们尝试测试从 Access 转换为 SQLExpress，但这并没有改变任何东西——即使转换后的网站也以同样的方式受到影响（所以它似乎不是 Access）。
然后我们尝试停止 IIS 中的所有站点，并仅重新激活一个访问者很少的站点，以查看它是否仅在向服务器发送许多请求时才出现。但是效果还是出现了，重启了IIS，重启了整机，IIS只激活了一个网站。它似乎完全独立于效果的数量，就像服务器（而不是：IIS 的 asp-引擎）以周期性模式忙于自身。
我们在性能监视器中看到的（见截图）：当requests/sec在某个时刻下降到0时，当效果开始时，执行的请求数从正常水平（看起来"logical" 对我来说，但只描述了效果，而不是证明它来自哪里）。在效果消失前几秒，request/sec 再次增长并且这些计数器恢复到正常值。
一年前我们在 Windows 2008-Server 上遇到过类似的问题，其中站点 运行 几年没有任何问题，然后它从无到有。在另一个托管商的服务器上测试了一些网站后，我们发现，问题没有出现在他的 Windows 2012 R2 的服务器上（并且整整一年都没有出现，同时托管了我们的 3 个那里的网站）。在另一个主机虚拟 Windows 2012R2-Server 上，我们有另一个托管站点，其流量比我们大多数其他站点都多，而且自从整整一年以来，问题也没有出现。所以我们的托管商切换到 WinServer2012R2 并且 - 宾果游戏 - 所有问题都消失了。从那一刻起，所有网站都再次表现出色，除了 OS.
没有任何改变
我们随后停止调查该问题，认为该问题与 OS 有关。但大约 9 个月后，它再次出现，经过数小时的调查，我们不知道要搜索什么以及该做什么（除了将我们所有的网站移至其他托管服务器，这不是真正的解决方案对于这个问题，我们不能gua运行tee，这个效果以后有时不会再出现在这台机器上了。
我自己最终找到了一个解决方案，但是是以一种完全随机的方式。经过几周寻找问题的解决方案后，我着手清理服务器的硬盘并删除了 Windows/temp-folder 中的所有文件（> 18.000 个文件！）。从这一刻（4 天前）开始，所描述的响应延迟就再也没有出现过！但是在该文件夹中创建了一小部分新的 .tmp 文件。
我的理论是：也许每次用户访问其中一个网站（打开与其 Access 数据库的连接，导致数据库文件夹中出现 .ldb 文件）时，一个随机（？）命名的 .tmp 文件（如：jet12f0.tmp）在 Windows/temp 文件夹中并行创建。随着数据库连接关闭和 .ldb 消失，这些文件 "normally" 再次被删除。也许某些连接没有正确关闭，因此 Windows/temp 文件夹中相应的 .tmp 文件作为 "orphan" 永久存在。随着时间的流逝，文件夹中充满了这些孤立的文件。然后它来了，应该生成一个新的 .tmp 文件，但名称仍然存在 "orphaned" .tmp 文件。现在这会导致服务器停止所有操作，因为不可能建立新文件，命名为现有文件。 15 到 20 秒后，冲突通过某种机制（我不知道）解决，并且一切再次完美运行，直到大约 45 秒后出现下一个冲突。等等...
我必须假设：这只是一个 "amateur" 理论，我不是服务器 "Guru"。
不时清理这个临时文件夹似乎可以防止服务器出现这种情况，因为没有 file/naming 冲突。
我同意：真正的解决方案是在代码中找到问题（如果有的话），但我们可以接受这种情况，将查找问题的努力与仅清理一次临时文件夹进行比较在一个月左右 ;-)
我有一堆（大约 50 个）经典 ASP-Sites on Win2012R2 with Access-Databases，这让我们抓狂。
此服务器上所有站点的所有 asp-页面 运行 平稳运行大约 45 秒，在此期间之后，它们（全部）完全停止响应任何点击 15 到 20 秒，然后这种延迟在接下来的 45 秒内再次消失，就像它以前从未存在过一样，它再次出现 - 依此类推。这个效果是几周前从无到有，经过几个月没有任何问题。
静态 HTML- 页面不受影响，而且看起来，即使 asp- 页面没有连接到他们的数据库 运行 也很好。因此，我们尝试测试从 Access 转换为 SQLExpress，但这并没有改变任何东西——即使转换后的网站也以同样的方式受到影响（所以它似乎不是 Access）。
然后我们尝试停止 IIS 中的所有站点，并仅重新激活一个访问者很少的站点，以查看它是否仅在向服务器发送许多请求时才出现。但是效果还是出现了，重启了IIS，重启了整机，IIS只激活了一个网站。它似乎完全独立于效果的数量，就像服务器（而不是：IIS 的 asp-引擎）以周期性模式忙于自身。
我们在性能监视器中看到的（见截图）：当requests/sec在某个时刻下降到0时，当效果开始时，执行的请求数从正常水平（看起来"logical" 对我来说，但只描述了效果，而不是证明它来自哪里）。在效果消失前几秒，request/sec 再次增长并且这些计数器恢复到正常值。
一年前我们在 Windows 2008-Server 上遇到过类似的问题，其中站点 运行 几年没有任何问题，然后它从无到有。在另一个托管商的服务器上测试了一些网站后，我们发现，问题没有出现在他的 Windows 2012 R2 的服务器上（并且整整一年都没有出现，同时托管了我们的 3 个那里的网站）。在另一个主机虚拟 Windows 2012R2-Server 上，我们有另一个托管站点，其流量比我们大多数其他站点都多，而且自从整整一年以来，问题也没有出现。所以我们的托管商切换到 WinServer2012R2 并且 - 宾果游戏 - 所有问题都消失了。从那一刻起，所有网站都再次表现出色，除了 OS.
没有任何改变我们随后停止调查该问题，认为该问题与 OS 有关。但大约 9 个月后，它再次出现，经过数小时的调查，我们不知道要搜索什么以及该做什么（除了将我们所有的网站移至其他托管服务器，这不是真正的解决方案对于这个问题，我们不能gua运行tee，这个效果以后有时不会再出现在这台机器上了。
我自己最终找到了一个解决方案，但是是以一种完全随机的方式。经过几周寻找问题的解决方案后，我着手清理服务器的硬盘并删除了 Windows/temp-folder 中的所有文件（> 18.000 个文件！）。从这一刻（4 天前）开始，所描述的响应延迟就再也没有出现过！但是在该文件夹中创建了一小部分新的 .tmp 文件。
我的理论是：也许每次用户访问其中一个网站（打开与其 Access 数据库的连接，导致数据库文件夹中出现 .ldb 文件）时，一个随机（？）命名的 .tmp 文件（如：jet12f0.tmp）在 Windows/temp 文件夹中并行创建。随着数据库连接关闭和 .ldb 消失，这些文件 "normally" 再次被删除。也许某些连接没有正确关闭，因此 Windows/temp 文件夹中相应的 .tmp 文件作为 "orphan" 永久存在。随着时间的流逝，文件夹中充满了这些孤立的文件。然后它来了，应该生成一个新的 .tmp 文件，但名称仍然存在 "orphaned" .tmp 文件。现在这会导致服务器停止所有操作，因为不可能建立新文件，命名为现有文件。 15 到 20 秒后，冲突通过某种机制（我不知道）解决，并且一切再次完美运行，直到大约 45 秒后出现下一个冲突。等等...
我必须假设：这只是一个 "amateur" 理论，我不是服务器 "Guru"。
不时清理这个临时文件夹似乎可以防止服务器出现这种情况，因为没有 file/naming 冲突。
我同意：真正的解决方案是在代码中找到问题（如果有的话），但我们可以接受这种情况，将查找问题的努力与仅清理一次临时文件夹进行比较在一个月左右 ;-)