c# - 使用时间戳跟踪并发 Web 服务请求

Question

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

在 Web 服务类的构造函数中，我使用 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 服务传输的开始？

Answer 1

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

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

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

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

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

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