我的ASP.NET应用程序需要很长时间才能在iisreset或app域回收后加载第一页请求。
有没有办法可靠地衡量应用领域回收所需的时间？
答案 0 :(得分：0)
如果没有编写监控进程的应用程序并等待CPU时间达到零，那么您最有可能需要使用秒表并重新启动几次。当你进入许多秒的时间时，毫秒不再重要。所以，秒表应该足够好了。
答案 1 :(得分：0)
您可以使用分析器，通过使用不同的cpu采样模式测量瓶颈来浏览代码等。像dotTrace这样的工具。 :) http://www.jetbrains.com/profiler/
答案 2 :(得分：0)
我们遇到了类似的问题，我不知道我们的经验会对您有所帮助。幸运的是，这发生在我们第一次调查面向服务的体系结构的时候，因此我们对使用Web服务与其他获取数据的方法相比如何影响性能非常感兴趣。
我不是说我们的 结果 会对您有所帮助，但可能是 方法 。
我们实际上花了两个完整的8小时工作日，除了测试不同的连接方案外，我们特别好奇与通过XML而不是二进制数据获取数据相关的额外带宽。我们完全期望通过获取XML数据来降低性能，我们假设这些数据在整个网络中都是更多的字节。
我不会进入结果，因为这本身就是一个10页的文档，但是当我们从以.Net语言访问数据的Web服务获取数据时，我们发现了一个有趣的延迟。在iSeries上（AS / 400，System i，或者这些天的新术语）。就像你描述的那样，第一次获取数据的调用需要一段时间，但随后的调用会更快。
事实证明，我们使用的连接类型（Microsoft提供的ODBC）是我们通过查看网络数据包的罪魁祸首。
我们测量了客户端和Web服务之间以及Web服务和iSeries（数据存储）之间的网络数据包，我们发现由于Web服务第一次连接到iSeries而导致延迟，来回发送了几个不必要的数据包。
简而言之，Windows端会发送连接请求，等待几毫秒，然后发送另一个请求。同时，iSeries的响应速度很慢，所以在第一次尝试连接时，有四个从Windows端连接到iSeries端的调用，然后是来自iSeries的四个响应，这些响应被Windows端忽略（因为连接的Windows端已经放弃了）。最后，在4-6次尝试之后，建立了连接。之后，连接必须已合并，因为后续连接在短时间内很快。但是，如果时间过去了（我们从未确定需要多长时间才会发生这种情况），缓慢的初始连接重新浮出水面。
所以，在经历了这么长时间的喷射之后，@ Aggelos Mpimpoudis建议分析你自己的代码。我的建议是找一个有经验和工具来分析网络数据包并分析整个过程的人。你或许可以追查那个罪魁祸首。
顺便说一下，在我们使用Ibm.Data.Db2.iseries而不是System.Data.Odbc驱动程序切换到连接到iSeries之后我们的问题变得更好了在我们有足够的Web服务写入调用iSeries的频率之后足以使汇集的连接保持开放。