通过 HttpHandlers 和 HttpModules 测量 ASP.NET 2.0 中的网络性能

发布于 2024-07-14 01:40:42 字数 626 浏览 10 评论 0原文

我们有一个依赖于 HttpModule 和 HttpHandlers 的性能测量模块,其工作方式如下:

  1. 请求进入服务器以获取页面。
  2. HttpModule_Begin 在 cookie 中写入开始时间。
  3. HttpModule_End 在 cookie 中写入结束时间。
  4. 在客户端,页面加载完成后,通过 AJAX 发出特殊请求 由 HttpHandler_ProcessRequest 处理
  5. 在 HttpHandler_ProcessRequest 中,从先前 HttpModule_End 写入的结束时间(存储在 cookie 中)中减去 DateTime.Now 并将其存储在数据库中。 我忘记提到的一件事:所有数据都是通过 cookie 共享的,因此 HttpHandler 只是从 cookie 中提取数据,而不需要任何会话 ID 等...... 所有参与者都在同一时区。

此过程在大多数情况下工作正常,但在某些情况下报告网络时间超过一小时! 这表明在写入结束时间和触发 AJAX 请求之间存在非常长的时间间隔,或者在触发 AJAX 请求和到达应用程序服务器的时间之间存在较长的时间间隔。 我正在尝试找出可能导致此问题的原因。 为什么操作不会简单地超时?

We have a performance measurement module that relies on HttpModule and HttpHandlers and works like this:

  1. Request comes in to server for a page.
  2. HttpModule_Begin writes start time in the cookie.
  3. HttpModule_End writes end time in the cookie.
  4. On client, when page load is finished, fire off a special request via AJAX
    that is handled by HttpHandler_ProcessRequest
  5. In HttpHandler_ProcessRequest subtract DateTime.Now from end time written by the previous HttpModule_End (which is stored in the cookie) and store it in the database.
    One thing I forgot to mention: all data is shared via a cookie, so the HttpHandler, just pulls the data from the cookie without any session id's, etc...
    All participants are in the same time zone.

This process works fine for most cases, but there are some instances that report network time in excess of an hour!
This indicates a very large passage of time between the the writing of end time and firing off the AJAX request or a large passage of time between firing off AJAX request and the time it gets to the app server.
I am trying to figure what could be causing this issues in the wild. Why does the operation not simply time out?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

白昼 2024-07-21 01:40:42

扩展您的故障排除:将值附加到 IIS 日志 (HttpContext .Current.Response.AppendToLog(string))。

IIS 日志将显示您的条目,您可以确定这些请求的实际记录时间。 您可以附加任何您想要的内容,它会显示在日志的查询字段中(假设您使用的是 W3C 格式)。

如果您遇到请求延迟(如证据所示),您可以验证它。
这将为您提供 IIS 日志,作为与 cookie 中记录值的比较源。

Extend your troubleshooting: append values to the IIS log (HttpContext.Current.Response.AppendToLog(string)).

The IIS log will show your entries and you can determine when those requests were actually recorded. You can append whatever you want and it shows up in the query field of the log (assuming you're using W3C format.)

If you're experiencing delays in requests, as the evidence suggests, you can verify it.
This will give you the IIS log as a comparative source against the recorded values in cookies.

梓梦 2024-07-21 01:40:42

您是否包含一些唯一的 ID,允许 AJAX 请求处理程序确定用于计算的结束时间? 如果不是,则可能已经在客户端上呈现了足够的页面,导致 AJAX 请求实际上是在结束时间写入数据库之前发出的,并且它使用了错误的结束时间。

Are you including some unique id that allows the AJAX request handler to figure out the which end time to use for the calculation? If not, perhaps enough of the page has been rendered on the client that the AJAX request is actually coming before the end time has been written to the database and it is using the wrong end time.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文