我认为这张图片最好.
很简单,随着时间的推移,响应时间变得越来越糟,直到午夜某个时候发生了一些事情并且它几乎恢复到正常状态.我们在IIS上,这个页面恰好仍然在Classic ASP中,但这种情况发生在所有页面上,甚至是普通的HTML页面,我认为它排除了sql连接问题.
我想我的问题是,我从哪里开始寻找？我经历了常规日志,没有看到任何跳出来的东西.但事情显然正在发生,我不知道从哪里开始.
在我进入实际响应之前,只需在HTML页面上快速查看一下：一般来说,应用程序池一次只能响应一定数量的请求.如果它忙于响应对动态页面的请求,那么它可能没有任何线程来为静态页面提供服务.出于这个原因,动态页面上的代码问题可能会产生静态页面“缓慢”服务的错觉.我的观点是,不排除代码或sql.
例如：如果您有100个页面同时点击数据库或API,并且所有100个页面都在等待响应,则可能会阻止请求101直到前100个中的1个完成.
现在,您可以做很多事情来帮助您诊断此问题：
>您的负载情况通常如何？这会产生很大的不同 – 可能是您总是遇到问题,但在您的网站实际收到负载之前,您无法看到影响.您可以尝试使用JMeter之类的东西测试它(在分段中).
>启用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)