0

我已经对我的应用程序的后端进行了一些性能改进，并且为了向 GUI 的最终用户展示好处，我们一直在使用 Trace.axd 页面进行计时。（前端是 .Net 1.1，后端是 Java，通过 Web 服务连接。）

但是，这些时间显示新旧后端之间没有区别。

通过在后端放置一个断点并将请求保持 30 秒，我可以从 Trace.axd 中看到 POST 需要 3 毫秒，而 GET 需要 4 秒。我错过了大约26s...

POST应该是性能提升的地方，但是Trace页面上的时间似乎只包括发送请求的时间，而不是返回的时间。

有没有办法增加跟踪中信息的粒度以包括整个请求？还是有其他方法可以进行我需要的测量？

4

3 回答 3

1

好吧，我最终得到了我想要的东西。问题是 IIS 跟踪不包括 POST 返回所需的时间。

我发现我可以使用 Trace.Write() 将自定义条目添加到跟踪日志中，甚至可以使用 Trace.Write(string category, string message) 添加类别。

在 POST 完成后执行的代码中添加对 Trace.Write() 的调用给了我一个更好的数字。

尽管如此，它仍然不是很理想，因为它是自定义的，我有责任把它放在尽可能接近 POST 周期的末尾。

于 2008-10-15T14:43:47.060 回答
0

我不确定您是如何在 .NET 端发出请求的，但我假设某处涉及到 HttpWebRequest。我希望 HttpWebRequest.GetResponse() 在收到响应标头后立即返回。这样，您可以在其余部分仍在下载时开始处理大型响应的开始。如果您的跟踪消息是在调用 GetResponse 之前和之后立即出现的，那么您将看不到后端的整个执行时间。您可以在关闭响应后立即添加跟踪消息吗？

于 2008-10-15T12:23:02.333 回答
0

跟踪输出未显示您在制动点中花费的所有时间是不正常的。您是否检查了总时间列以查看它是否与您在请求中花费的时间相匹配？不要忘记其中一列仅显示自前面的跟踪语句以来所花费的时间。

如果您想在跟踪输出中获得更精细的数据，您可以添加自己的。TraceContext 类有两个方法，Warn 和 Write，它们在输出中添加行（warn 将其添加为红色）。

TraceContext 可以从每个页面或控件访问：只需使用 this.Trace.Warn() 或 this.Trace.Write() （我认为它也可以通过 HttpContext 类访问）。

于 2008-10-15T12:36:11.980 回答