【问题标题】:detecting undisposed web service calls (ASP.NET)检测未处理的 Web 服务调用 (ASP.NET)
【发布时间】:2009-12-09 20:27:38
【问题描述】:

我正在继承一个遗留项目,并且有一个页面调用了一个进行 Web 服务调用的方法。负载和性能测试检测到此页面有时需要很长时间才能关闭,但通常没问题,如果有一个挂起,则对该页面的所有其他请求都会挂起,直到第一个解决,然后它们都解决。

我认为这可能与正在实例化且未处置的 Web 服务有关,但我不知道如何才能更确定。我试图向 Dispose 方法添加一个委托,但这似乎永远不会触发。 (如果没有显式调用 Dispose,我不确定它会不会,但这并不重要。)

那么我可以在生产服务器或任何已部署的环境中寻找什么来观察这些请求堆积并发出(或以有序的方式处理,如果它们不是问题的话)?

【问题讨论】:

  • 附带说明,在开发阶段,您应该运行代码分析工具来检测这种反模式(在适当的时候不要调用 dispose)。 FxCop 可以在这种情况下提供帮助。

标签: asp.net web-services dispose


【解决方案1】:

您可以考虑使用 .NET Memory Profiler 之类的工具。您可以使用它附加到正在运行的应用程序,它可以找到并报告所有未处理的对象。

我想他们有两周的免费试用期。

【讨论】:

  • 我找不到专门检查打开的 Web 服务调用的方法,但这种暗示表明对象处于打开状态。当我明确关闭它们时,它看起来并没有太大的不同,但是 .NET Memory Profiler 并不适合初学者。我会继续努力的。
【解决方案2】:

在您的网络应用程序代码中,您可以在发送请求之前写入日志(事件日志、文本文件),并在收到响应后再次写入。包括一些关于请求的识别信息。添加时间戳。

如果您只想在调试时使用它,请将其包装在#debug 中。

或者,如果您想在发布模式下进行测试,您可以在 web.config 的 appSettings 中放置一个布尔值,这样您就可以关闭和打开日志记录。

【讨论】:

  • 我并不十分担心从请求回复到得到回复之间的时间。我更关心收到响应后会发生什么——我假设连接关闭并且不会无限期地占用有限数量的出站连接之一。找出 .NET 对这些调用的实际作用是问题所在。
  • 我在想这可能有助于“观察那些请求堆积起来然后出去(或以有序的方式处理”。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-11-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多