Отслеживание одновременных запросов веб-службы с отметками времени

Question

У меня есть веб-служба ASP.NET 4.0, которая принимает передачу файлов XML. В прошлом (с другой реализацией того же веб-сервиса) мы отслеживали параллелизм (количество файлов XML, принимаемых / обрабатываемых одновременно), используя временные метки. Я повторил это поведение в новой версии веб-службы следующим образом:

В конструкторе для класса веб-службы я записываю ConnectionStartTime, используя HttpContext.Current.Timestamp

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

После того, как я закончу обработку файла XML в WebMethod, я вставляю файл в базу данных (запись ConnectionEndTime) и возвращаю ответ пользователю. Я выполняю вставку базы данных в новом Thread, поэтому конечному пользователю не нужно ждать, пока произойдет вставка, чтобы получить свой ответ.

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

Теперь я пытаюсь измерить, сколько одновременных передач XML мы достигли двумя способами:

1. Счетчики производительности

• ASP.NET Apps v4.0 \ Выполнение запросов - значение этого счетчика достигло 52.
• ASP.NET Apps v4.0 \ Requests Queued - этот счетчик достиг максимального значения 19.

Для меня это означает, что я должен увидеть точку, где у нас есть 33 записи с перекрытием ConnectionStartTime и ConnectionEndTime.

2. Запросы по меткам времени - В этот вопрос я ссылаюсь на запрос, который я использую для вычисления количества одновременных передач на основе ConnectionStartTime и ConnectionEndTime. Это datetime поля в базе данных SQL Server. Примечание: Запрос в этом вопросе является переработанной версией алгоритма, который мы использовали в течение последних 3 лет для определения параллелизма, поэтому он может быть не на 100% правильным, но другие реализации алгоритма (Excel макросы и т. д.) были проверены.

Моя проблема в том, что эти два метода никогда не совпадают. Максимальный результат от запроса меток времени достиг 10, в то время как счетчики производительности предполагают, что максимум должен быть 30+. Мне трудно найти, где расхождение. Я делаю ошибку в том, как я записываю свои метки времени? Не записывает ли значение HttpContext.Current.Timestamp начало передачи в веб-службу?

Answer 1

Использование запуска потока приведет к расхождению между вашими данными и счетчиками ASP.NET (в основном из-за того, как вы написали функцию потока. Я бы изменил ее на:

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

Не уверенесли это единственный источник разницы, но с помощью своего кода вы измеряете время, необходимое для обработки запроса И запускаете поток и запускаете команду для базы данных, чтобы записать время.

Мой кодизмеряет время обработки запроса только путем захвата конечного времени в замыкании перед вращением потока. Он должен приблизиться к счетчикам производительности ASP.NET. Не уверен, что он будет учитывать все расхождения, но это должно помочь.

Я согласен с предыдущими комментаторами в том, что не следует запускать новый поток с каждым таким запросом. Для раскрутки новых потоков требуется время и очень много памяти. Если это высокопроизводительное приложение, оно определенно будет иметьэффект. Использование QueueUserWorkItem было бы лучше, хотя использование ThreadPool имеет свой собственный набор проблем и ограничений.

В качестве заключительного комментария у используемого вами шаблона есть некоторые другие потенциальные ошибки, которые будут появляться по мере увеличения частоты запросов (проблемы с очередями, параллелизмом и узкими местами).Могу поспорить, что в вашей текущей реализации расхождение растет с частотой запросов.Если это высокопроизводительное или чувствительное к производительности приложение, я бы использовал другой подход для измерения параллелизма полностью.