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

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

在Web服务类I的构造函数中，使用

HttpContext.Current.Timestamp

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

在

WebMethod

中处理完XML文件后，我将该文件插入数据库（记录

connectionedtime

），并将响应返回给用户。我在一个新的

线程中执行数据库插入

，这样最终用户就不必等待插入发生才能收到响应

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

现在，我试图衡量我们通过两种方法实现了多少并发XML传输：

1。性能计数器

• ASP.NET Apps v4.0\正在执行的请求-此计数器在52处达到峰值
• ASP.NET Apps v4.0\请求排队-此计数器在19时达到峰值

对我来说，这意味着我应该看到这样一个点：我们有33条记录重叠

ConnectionStartTime

和

connectionedtime

2。查询时间戳 -在本文中，我引用了用于根据

ConnectionStartTime

和

connectionedtime

计算并发传输数的查询。这些是SQL Server数据库中的

datetime

字段注意：该问题中的查询是我们在过去3年中用于确定并发性的算法的修改版本，因此可能不是100%正确，但该算法的其他实现（Excel宏等）已经过验证

---

我的问题是，这两种方法永远不会一致。查询时间戳的最大结果达到10，而性能计数器建议最大结果应为30+。我很难找到差异所在。我记录时间戳的方式是否出错？

HttpContext.Current.Timestamp

值是否不记录传输到web服务的开始

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

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

不确定这是否是造成差异的唯一原因，但通过代码，您可以测量处理请求、启动线程并向数据库发出命令以记录时间所需的时间

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

我同意前面的评论，即您不应该在每个请求中都启动一个新线程。启动新线程需要时间，而且占用内存非常大。如果这是一个高性能应用程序，它肯定会产生效果。使用QueueUserWorkItem会更好，尽管使用ThreadPool有自己的一组线程关注和限制

---

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

不确定是否相关，但是……除非您有非常好的理由，否则不要使用Thread.Start（）在ASPNET中。使用线程池。感谢您的提示。不确定它是否会影响时间戳问题，但还是有所改进。