响应时间随着时间的推移而变慢，从哪里开始故障排除？

Question

当我提出这个问题时，我的 IT 人员只是耸了耸肩，所以我转向 SE 寻求帮助。

我认为这张图最能说明问题。

很简单，随着时间的推移，响应时间变得越来越糟，直到午夜左右发生一些事情，它几乎恢复正常。我们在 IIS 上，这个页面碰巧仍然在经典 ASP 中，但这发生在所有页面上，甚至是纯 HTML 页面，我认为这排除了 SQL 连接问题。

我想我的问题是，我从哪里开始寻找？我浏览了常规日志，没有看到任何跳出来的东西。但显然有些事情正在发生，我不知道从哪里开始。

Answer 1

造成这种情况的原因有很多 - 不幸的是，我们可能需要更多信息。

在开始我的实际响应之前，先简要介绍一下您的 HTML 页面：一般来说，应用程序池一次只能响应一定数量的请求。如果它忙于响应动态页面的请求，那么它可能没有任何线程来为静态页面提供服务。出于这个原因，动态页面上的代码问题可能会造成静态页面正在“缓慢”提供服务的错觉。我的观点是，不要排除代码或 SQL。

例如：如果您有 100 个页面同时访问数据库或 API，并且所有 100 个页面都在等待响应，则请求 101 可能会被阻塞，直到前 100 个页面中的一个完成。

现在，您可以做很多事情来帮助您诊断此问题：

• 您的负载配置文件通常是什么样的？这有很大的不同 - 您可能总是遇到问题，但在您的站点实际接收负载之前您无法看到影响。您可以尝试使用 JMeter 之类的东西来测试它（在 staging 中）。

• 启用 IIS 日志（如果您尚未启用），然后查看它们以查看哪些请求耗时最长。您可以使用Log Parser（来自 Microsoft）之类的工具对您的日志运行类似 SQL 的查询（或者甚至将您的日志转储到 SQL 数据库中），如果这能让生活更轻松。一旦您知道哪些页面花费的时间最长，您就可以将一些注意力集中在它们上。

• 您的应用程序有日志吗？如果没有，您应该考虑添加一些日志记录。如果您已经有日志，他们会怎么说？您的应用程序是否抛出异常？有什么东西一直在失败吗？

• 您的应用程序池使用了多少内存？内存泄漏是一个明显的候选者，但您应该很容易看到。使用 Windows 的内置性能监视器来跟踪一天中应用程序池消耗的内存，并查看它是否随着时间的推移而增加。

• 正如我在开头提到的，SQL 可能仍然是一个问题。我会建议在看看数据库服务器，看看是否有任何长时间运行或阻塞，查询（如中sys.dm_exec_requests，看看wait_type，wait_time，blocking_session_id和total_elapsed_time）。

• 使用TCPView（另一个 Microsoft 工具）之类的工具检查您的应用程序池已打开的连接数。您的应用程序池将在可能的情况下尝试重用连接，但您可能会看到许多打开的应用程序池连接。您可以从中看到的一件有趣的事情是，您现在打开了许多与 SQL 数据库或应用程序使用的任何外部 API 的连接。

• 使用应用程序性能和监控工具。AppDynamics 或类似的工具将能够帮助查明代码中执行缓慢的部分。不幸的是，要有效地使用这些工具需要一些学习曲线，但它们在帮助诊断应用程序问题方面非常强大。

更新

如果您有内存泄漏，重新启动应用程序池可能有助于解决问题，但您需要注意这一点：可能会有一些不利影响。重新启动应用程序池后，应用程序将开始将静态对象加载到内存中，等等。这可能需要很长时间（可能是 5-10 分钟或更长时间），具体取决于应用程序的复杂程度。在此期间，对您的服务器的请求可能会延迟，从而使问题看起来更加严重。

如果您运行的是单个服务器，您的站点可能会在应用程序重新启动时暂时不可用（由于应用程序池很忙，无法响应请求）。如果您在使用负载均衡器的场中运行，负载均衡器可能会在应用程序池重新启动时将您的服务器丢弃，这可能会将所有流量定向到其他服务器并使它们过载。不要同时重新启动所有服务器上的应用程序池，并在将服务器重新引入服务器场之前尝试“预热”应用程序池（通过模拟针对服务器的请求）。

换句话说：除非绝对是内存泄漏问题，否则可能不值得重新启动应用程序池，因为问题可能会立即重新出现。

注意：重新启动应用程序池不会影响任何当前正在运行的请求。这些将继续完成，除非你强行关机的应用程序池（如Crtl+ Alt+ Del）