Настройка веб-приложения на C #: PerformWaitCallback - PullRequest
Новая
       61

Настройка веб-приложения на C #: PerformWaitCallback

13 голосов
/ 21 ноября 2011

Я использую dotTrace Performance 4.5 для профилирования веб-приложения .NET 3.5 C #. Когда я записываю один «запрос пользователя» (загрузка страницы), я вижу 11 потоков с примерно одинаковым временем, 7644 мсек.

  • Большинство описаний потоков содержат только: 100% [Собственный или оптимизированный код] - 7644 мс
  • Один говорит: 100% Microsoft.VisualStudio.WebServer.WebServerApp.Main(String[])
  • Последнее чтение:
    • 86% System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object)
    • 14% PerformWaitCallback (1094 мс) >> 12% = ProcessRequest

Можете ли вы сказать мне:

  • Почему так много тем? (ресурсы изображений, AJAX, JavaScript)
  • Что такое PerformWaitCallback?
  • Почему 7644 мс только на 1094 мс работы?

Ответы [ 2 ]

3 голосов
/ 03 декабря 2011

Почему так много тем?(ресурсы изображений, AJAX, JavaScript)

Веб-сервер создает пул потоков для управления входящими запросами, и в пуле имеется несколько потоков.

Чтотакое PerformWaitCallback?

Не знаю наверняка, но похоже, что код ожидает завершения потока пула потоков.

Почему 7644 мс длятолько 1094 мс работы?

Похоже, профилировщик считает время, которое некоторые потоки тратят на ожидание новой работы.Я не использовал dotTrace, но у большинства профилировщиков есть способ настроить их так, чтобы они могли определить, когда потоки ожидают или работают - основываясь на опубликованной вами информации, я подозреваю, что профилировщик настроен не совсем правильно.

1 голос
/ 20 мая 2013

Относительно PerformWaitCallback, вот что говорит эталонный источник:

Обратный помощник. Эта функция отправляет запросы пользовательские функции обратного вызова. Рабочие элементы извлекаются из домена приложения очередь в цикле, пока либо нет больше работы или квант имеет истекший. Квант применяется для обеспечения справедливости среди AppDomains.

Вы можете увидеть полный код здесь .

Кстати, я не уверен, что вы увидите это в .NET 4.5 - снова из справочного источника (не удалось найти онлайн-версию, вам придется скачать ее с http://referencesource.microsoft.com/):

//This type is necessary because VS 2010's debugger looks for a method named 
///_ThreadPoolWaitCallbacck.PerformWaitCallback 
//on the stack to determine if a thread is a ThreadPool thread or not.  
//We have a better way to do this for .NET 4.5, but
//still need to maintain compatibility with VS 2010.  
//When compat with VS 2010 is no longer an issue, this type may be removed.
internal static class _ThreadPoolWaitCallback
{ 
    [System.Security.SecurityCritical]
    static internal bool PerformWaitCallback() 
    { 
        return ThreadPoolWorkQueue.Dispatch();
    } 
}
...