使用时间戳跟踪并发 Web 服务请求答案

【问题标题】：Tracking Concurrent Web Service Requests with Timestamps使用时间戳跟踪并发 Web 服务请求
【发布时间】：2011-05-16 13:35:25
【问题描述】：

我有一个接受 XML 文件传输的 ASP.NET 4.0 Web 服务。过去（使用相同 Web 服务的不同实现）我们使用时间戳来跟踪并发性（同时接收/处理的 XML 文件的数量）。我已经在新版本的网络服务中复制了这种行为：

在 Web Service 类的构造函数中，我使用 HttpContext.Current.Timestamp 记录 ConnectionStartTime

public class MyWebService : System.Web.Services.WebService
{
  public MyWebService()
  {
    ConnectionStartTime = HttpContext.Current.Timestamp
  }
}

处理完WebMethod 中的XML 文件后，我将文件插入数据库（记录ConnectionEndTime）并将响应返回给用户。我在一个新的Thread 中执行数据库插入，因此最终用户不必等待插入发生来接收他们的响应。

new Thread (() =>
  {
    insertIntoDatabase(ConnectionStartTime, ConnectionEndTime=Datetime.Now, xmlFile);
  }).Start();
return responseToUser;

现在我正在尝试使用两种方法来衡量我们已经达到了多少并发 XML 传输：

1.性能计数器

ASP.NET Apps v4.0\Requests Executing - 此计数器的峰值为 52。
ASP.NET Apps v4.0\Requests Queued - 此计数器在 19 处达到峰值。

对我来说，这意味着我应该看到我们有 33 条记录重叠 ConnectionStartTime 和 ConnectionEndTime。

2。查询时间戳 - 在this question 中，我引用了我用来计算基于ConnectionStartTime 和ConnectionEndTime 的并发传输数的查询。这些是 SQL Server 数据库中的 datetime 字段。 注意：该问题中的查询是我们过去 3 年用来确定并发性的算法的修改版本，因此它可能不是 100% 正确，但算法的其他实现（ Excel 宏等）已经过验证。

我的问题是这两种方法永远不会对齐。查询时间戳的最大结果达到 10，而性能计数器建议最大值应为 30+。我很难找到差异所在。我在记录时间戳的方式上是否犯了错误？ HttpContext.Current.Timestamp 值是否不记录传输到 Web 服务的开始？

【问题讨论】：

不确定是否相关，但是......除非你有一个非常好的理由，否则不要在 ASPNET 中使用 Thread.Start()。使用线程池。 stackoverflow.com/questions/684640/…
感谢您的提示。不确定它是否会影响时间戳问题，但仍然有所改进。

标签： c# asp.net web-services datetime concurrency

【解决方案1】：

使用线程启动会导致您的数据和 ASP.NET 计数器之间存在差异（主要是因为您编写线程函数的方式。我会将其更改为：

DateTime EndTime = DateTime.Now
new Thread (() =>
{
    insertIntoDatabase(ConnectionStartTime, ConnectionEndTime=EndTime, xmlFile);
}).Start();
return responseToUser;

不确定它是否是差异的唯一来源，但您正在使用您的代码测量处理请求并启动线程并向数据库发出命令以记录时间所需的时间。

我的代码仅通过在启动线程之前捕获闭包中的结束时间来测量处理请求的时间。它应该更接近 ASP.NET 性能计数器。不确定它是否会解决整个差异，但它应该会有所帮助。

我同意以前的评论者的观点，即您不应该对每个这样的请求都开始一个新线程。启动新线程需要时间并且非常占用内存。如果这是一个高性能应用程序，它肯定会产生影响。使用 QueueUserWorkItem 会更好，尽管使用 ThreadPool 有其自身的一组问题和限制。

作为最后的评论，您正在使用的模式还有一些其他潜在的陷阱，这些陷阱会随着您的请求率增加（排队、并发和瓶颈问题）而浮出水面。我敢打赌，在您当前的实现中，差异会随着请求率的增加而增加。如果这是一个高性能或对性能敏感的应用程序，我将使用不同的方法来完全测量并发性。

【讨论】：