在 iisreset 或应用程序域回收后，我的 ASP.NET 应用程序需要很长时间才能加载第一个页面请求。
有没有办法可靠地测量应用程序域回收所需的时间？
问问题
677 次
3 回答
0
如果没有编写一个监控进程并等待 CPU 时间归零的应用程序，您很可能需要使用秒表并重新启动几次。当您进入多秒计时时，毫秒就不再重要了。所以，秒表应该足够好了。
于 2009-09-12T00:57:25.513 回答
0
您可以使用分析器，通过使用不同的 cpu 采样模式测量瓶颈等来浏览代码。这样的工具就是 dotTrace。:) http://www.jetbrains.com/profiler/
于 2009-09-12T01:03:06.367 回答
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 的调用频率足以保持池连接打开。
于 2009-09-12T02:26:50.233 回答