计时 ASP.NET 应用程序中的初始启动
我的 ASP.NET 应用程序在 iisreset 或应用程序域回收后需要很长时间才能加载第一个页面请求。
有没有一种方法可以可靠地测量应用程序域回收所需的时间？
My ASP.NET app takes a long time to load the first page request after an iisreset or app domain recycle.
Is there a way to reliably measure the amount of time it takes for the app domain to recycle?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们也遇到过类似的问题，不知道我们的经验是否能帮到你。幸运的是，这发生在我们第一次研究面向服务的架构时，因此我们对与其他获取数据的方法相比使用 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 的调用频率足以保持池连接打开。
We had a similar issue, and I don't know if our experience will help you. Fortunately, this happened at a time when we were first investigating Service Oriented Architecture, so we were very interested in how using web services affects performance compared to other methods of getting data.
I'm not saying that our results will be helpful to you, but possibly the methodology.
We actually spent two full 8 hour days doing nothing but testing different connection scenarios, We were particularly curious about the added bandwidth associated with getting data via XML as opposed to as binary data. We fully expected a performance degradation simply from getting XML data, which we assumed would be more bytes across the network.
I won't go into the results, as that was a 10 page document in itself, but we DID find an interesting lag that occurred when we were getting data from a web service written in a .Net language that was accessing data on the iSeries (AS/400, System i, or whatever the new term is these days). Just like you described, the first call to get data took a while, but subsequent calls were quicker.
It turned out that the type of connection we were using (ODBC provided by Microsoft) was the culprit in our case by looking at the network packets.
We measured the network packets between the client and the web service, and also between the web service and the iSeries (data store) and we found that the lag was happening because the first time the web service made a connection to the iSeries, several unnecessary packets were being sent back and forth.
In a nutshell, the Windows side would send a connection request, wait a few milliseconds, then send another one. meanwhile, the iSeries was just slow to respond, so in the first attempt to connect, there were four calls to connect from the Windows side to the iSeries side, and then four responses from the iSeries, which were ignored by the Windows side (because the Windows side of the connection had given up). Finally after 4-6 attempts, a connection was established. After that, the connection must have been pooled, because subsequent connections within a short time were quick. However, if time elapsed (we never did determine how long was needed for this to happen), the slow initial connection resurfaced.
SO, after all of that long spew, @Aggelos Mpimpoudis had suggested profiling your own code. My suggestion would be to find someone who has experience and tools for analyzing Network packets and analyze the entire process. You may be able to trace down the culprit that way.
Incidentally, our problem got better after we switched to connecting to the iSeries using the Ibm.Data.Db2.iseries instead of the System.Data.Odbc driver AND after we had enough web services written that frequency of calls to the iSeries was enough to keep the pooled connection open.
如果不编写一个监视进程并等待 CPU 时间为零的应用程序，您很可能需要使用秒表并重新启动几次。当你进入很多秒的计时时，毫秒就不再重要了。所以，秒表应该足够好了。
Short of writing an app that monitors the processes and waits for the CPU time to hit zero, your most likely going to need to use a stopwatch and just restart things several times. When you get into many-second timings, the milliseconds don't really matter anymore. So, a stopwatch should be good enough.
您可以使用探查器，通过测量不同 CPU 采样模式的瓶颈等来浏览代码。类似的工具是 dotTrace。 :)
http://www.jetbrains.com/profiler/
You could use a profiler, navigating through code by measuring bottlenecks with different cpu sampling modes, etc. A tool like that is dotTrace. :)
http://www.jetbrains.com/profiler/