当我提起这个问题时，我的 IT 人员只是耸耸肩，所以我向 SE 寻求帮助。
我认为这张图片最能体现这一点。
很简单，随着时间的推移，响应时间变得越来越差，直到午夜左右发生一些事情，然后它又几乎恢复正常。我们在 IIS 上，这个页面恰好仍然是经典 ASP，但这种情况发生在所有页面上，甚至是纯 HTML 页面上，我认为这排除了 SQL 连接问题。
我想我的问题是，我应该从哪里开始查找？我浏览了常规日志，没有发现任何让我印象深刻的东西。但显然有些事情正在发生，我不知道从哪里开始。
答案1
有很多原因都可能导致这种情况——不幸的是，我们可能需要更多信息。
在我开始实际响应之前，我想简单说一下您的 HTML 页面：一般来说，应用程序池一次只能响应一定数量的请求。如果它忙于响应动态页面的请求，那么它可能没有剩余的线程来为静态页面提供服务。因此，动态页面上的代码问题会造成静态页面正在“缓慢”服务的假象。我的意思是，不要排除代码或 SQL。
举个例子：如果有 100 个页面同时访问数据库或 API，并且所有 100 个页面都在等待响应，则请求 101 可能会被阻止，直到前 100 个页面中的 1 个完成。
现在，您可以做很多事情来帮助您诊断此问题：
您的负载曲线通常是什么样的？这有很大的不同——也许你总是有问题，但直到您的网站实际收到负载时才能看到影响。您可以尝试使用 JMeter 之类的工具对此进行测试（在准备阶段）。
启用 IIS 日志（如果尚未启用），然后查看哪些请求耗时最长。您可以使用类似日志解析器（来自 Microsoft）对日志运行类似 SQL 的查询（或者甚至将日志转储到 SQL 数据库中），如果这能让生活更轻松的话。一旦您知道哪些页面花费的时间最长，您就可以将一些注意力集中在它们上面。
您的应用程序有日志吗？如果没有，您应该考虑添加一些日志记录。如果您已经有日志，它们会说什么？您的应用程序是否抛出了异常？是否有某些东西持续失败？
您的应用程序池使用了多少内存？内存泄漏是一个明显的候选对象，但你应该很容易发现。使用 Windows 的内置性能监视器跟踪应用程序池在一天中消耗的内存，并查看随着时间的推移内存是否会增加。
正如我在开头提到的，SQL 可能仍然是一个问题。我建议查看数据库服务器，看看是否有任何长时间运行或被阻止的查询（例如
sys.dm_exec_requests，查看wait_type、wait_time和blocking_session_id）total_elapsed_time。检查应用程序池打开了多少个连接，使用类似TCP查看器（另一个 Microsoft 工具）。您的应用程序池将尝试尽可能重复使用连接，但您可能会看到很多打开到应用程序池的连接。从中您可以看到一件有趣的事情，现在您已经打开了许多到 SQL 数据库或应用程序使用的任何外部 API 的连接。
使用应用程序性能和监控工具。AppDynamics 或类似工具将能够帮助找出代码中执行速度较慢的部分。遗憾的是，要有效地使用这些工具，需要一点学习时间，但它们在帮助诊断应用程序问题方面非常有效。
更新
如果出现内存泄漏，重新启动应用程序池可能会帮助解决问题，但您需要小心：这可能会产生一些不利影响。重新启动应用程序池后，应用程序将开始将静态对象加载到内存中等。根据应用程序的复杂程度，这可能需要很长时间（可能是 5-10 分钟或更长时间）。在此期间，对服务器的请求可能会延迟，从而导致出现问题变得更加严重。
如果您运行的是单台服务器，则应用程序重新启动时，您的网站可能会暂时不可用（由于应用程序池很忙，无法响应请求）。如果您在具有负载平衡器的服务器场中运行，则负载平衡器可能会在应用程序池重新启动时将您的服务器断开连接，这可以将所有流量导向其他服务器，并使它们超载。不要同时在所有服务器上重新启动应用程序池，并在将服务器重新引入服务器场之前尝试“预热”应用程序池（通过模拟对服务器的请求）。
换句话说：除非这肯定是内存泄漏的问题，否则可能不值得重新启动应用程序池，因为问题可能会立即重新出现。
笔记：重新启动应用程序池将不是影响任何当前正在运行的请求。除非您强制关闭应用程序池（例如Crtl++ ） ，Alt否则这些请求将继续完成Del
答案2
可能是代码很烂，内存泄漏，而且每晚都会重新启动应用程序池，从而重置应用程序状态。您是否尝试过以任何方式对其进行调试？测试服务器、调试器、分析器，所有这些都是在某种类似于生产的负载下进行的？
我的意思是，检查实际的服务器性能以确保没有缓慢的 IO 或服务器上的其他问题也是值得的。因此，请与您的 IT 部门合作以排除这种情况。根据您的环境，Perfmon、Solarwinds 或 SCOM 等词可能合适。但是，您也必须愿意自己做一些工作。
我曾经是一名 IT 人员，因为“网络应用程序运行缓慢”而受到指责，但实际上服务器上没有问题，但是代码中存在问题。
答案3
我刚刚收到通知说这个问题的浏览量达到了 1000，所以我想回来解释一下发生了什么。如果我还记得的话……
当时，我们有一个内部广告服务器，用于投放所有广告，并全天保存某种日志文件或每日统计数据。一天结束后，该文件被移至存档文件中。
因此，随着时间的推移，日志文件变得越来越大，它减慢了广告的投放速度，进而减慢了页面加载的完成速度，直到一天结束时日志文件被清除，一切恢复正常。