随着时间的推移，响应时间会减慢，从哪里开始进行故障排除？

有很多事情可能会导致这一点 – 不幸的是，我们可能需要更多的信息。

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

举个例子：如果你有100个页面全部同时打到一个数据库或者API，并且所有的100个都在等待响应，那么请求101可能被阻塞，直到前100个中的1个完成。

现在 ，你可以做很多事情来帮助你诊断这个问题：

• 什么是你的负载configuration文件像正常？ 这会造成很大的变化 – 这可能是因为您总是遇到问题，但是直到您的网站实际接收到负载时才能看到影响。 你可以试着用JMeter这样的东西来testing（分期）。

• 启用IIS日志（如果还没有的话） ，然后查看它们，看看哪些请求花费的时间最长。 您可以使用像Log Parser （来自Microsoft）的东西来针对您的日志运行类似于SQL的查询（或者甚至将您的日志转储到SQL数据库中），如果这样可以使生活更轻松。 一旦您知道哪些页面花费的时间最长，您可以将注意力集中在这些页面上。

• 你的应用程序是否有日志？ 如果没有，你应该考虑添加一些日志logging。 如果你已经有日志，他们说什么？ 你的应用程序是否有exception？ 有什么东西一直失败吗？

• 你的应用程序池使用多less内存？ 内存泄漏是一个明显的候选人，但你应该很容易看到。 使用Windows内置的性能监视器来跟踪应用程序池在一天中所占用的内存，并查看这一天是否会随着一天的进行而增加。

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

• 检查应用程序池已打开多less个连接 ，使用TCPView （另一个Microsoft工具）之类的东西。 您的应用程序池将尽可能重新使用连接，但您可能会看到许多与应用程序池的开放连接。 从这里可以看到一个有趣的事情，就是现在有很多连接可以向您的SQL数据库或您的应用程序使用的任何外部API打开。

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

更新

如果您有内存泄漏，重新启动您的应用程序池可能有助于解决问题，但您需要小心：可能会有一些不利影响。 重新启动应用程序池后，应用程序将开始将静态对象加载到内存中等。根据应用程序的复杂程度，这可能需要很长时间（可能需要5-10分钟或更长时间）。 在这段时间内，对您的服务器的请求可能会延迟，使问题似乎加剧。

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

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

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

这可能是代码是垃圾和泄漏的内存，每晚都会重新启动应用程序池，重置应用程序状态。 你有没有尝试以任何方式进行debugging？ testing服务器，debugging器，分析器，同时在某种类似于生产的负载下运行？

我的意思是，查看实际的服务器性能也是值得的，以确保IO没有缓慢，或者服务器正在进行其他操作。 因此，请与您的IT部门合作排除这个问题。 像Perfmon或Solarwinds或SCOM这样的词可能是合适的，这取决于你的环境。 但是，你也必须愿意在你身边做工作。

我一直在那些被指责为“慢速networking应用程序”的IT人士的鞋子里面，当时服务器上没有任何问题，但代码中存在问题。