Асинхронные страницы в платформе ASP.NET - где другие потоки и как она повторно прикреплена?

Асинхронные страницы в ASP.NET используют асинхронные обратные вызовы, а асинхронные обратные вызовы используют пул потоков, и это то же самое Пул потоков, используемый для обслуживания запросов ASP.NET.

Однако не все так просто. .NET ThreadPool имеет два типа потоков - рабочие потоки и потоки ввода-вывода. Потоки ввода-вывода используют так называемый порт завершения ввода-вывода , который (значительно упрощая здесь) является беспоточным или независимым от потоков средством ожидания завершения операции чтения / записи в дескрипторе файла. с последующим запуском метода обратного вызова.

(Обратите внимание, что дескриптор файла не обязательно относится к файлу на диске; для Windows это может быть сокет, канал и т. Д.)

A Типичному веб-разработчику .NET не обязательно знать об этом. Конечно, если вы пишете реальный веб-сервер или какой-либо другой сетевой сервер, вам обязательно нужно будет узнать об этом, потому что они являются единственным способом обработки сотен входящих подключений, не создавая при этом сотни потоков для их обслуживания. Если вам интересно, есть учебник Managed I / O Completion Port (CodeProject).

В любом случае, возвращаясь к теме; когда вы взаимодействуете с пулом потоков на высоком уровне, т.е.написав:

ThreadPool.QueueUserWorkItem(s => DoSomeWork(s));

Это не использует порт завершения ввода / вывода. Всегда. Он отправляет работу в один из обычных рабочих потоков, управляемых пулом потоков. То же самое, если вы используете асинхронные обратные вызовы:

Func<int> asyncFunc;

IAsyncResult BeginOperation(object sender, EventArgs e, AsyncCallback cb,
    object state)
{
    asyncFunc = () => { Thread.Sleep(500); return 42; };
    return asyncFunc.BeginInvoke(cb, state);
}

void EndOperation(IAsyncResult ar)
{
    int result = asyncFunc.EndInvoke(ar);
    Console.WriteLine(result);
}

Опять же - то же самое. Внутри EndOperation вы работаете в потоке ThreadPool worker . Вы можете проверить это, вставив следующий код отладки:

void EndSimpleWait(IAsyncResult ar)
{
    int maxWorkers, maxIO, availableWorkers, availableIO;
    ThreadPool.GetMaxThreads(out maxWorkers, out maxIO);
    ThreadPool.GetAvailableThreads(out availableWorkers, out availableIO);
    int result = asyncFunc.EndInvoke(ar);
}

Вставьте туда точку останова, и вы увидите, что availableWorkers на единицу меньше, чем maxWorkers , а maxIO и availableIO одинаковы.

Но некоторые асинхронные операции в .NET являются «специальными». На самом деле это не имеет ничего общего с ASP.NET напрямую - они также будут использовать порты завершения ввода-вывода в приложениях Winforms или WPF. Примеры:

• System.Net.Sockets.Socket ( BeginReceive ) и множество других методов BeginXYZ )
• System.IO.FileStream ( BeginRead и BeginWrite )
• System.ServiceModel.ClientBase ( BeginInvoke )
• System.Net.WebRequest ( BeginGetResponse )

И так далее, это далеко не полный список. Практически почти каждый класс в .NET Framework, который предоставляет свои собственные методы BeginXYZ и EndXYZ и предположительно может выполнять любой ввод-вывод, вероятно, использует порты завершения ввода-вывода. Это сделано для того, чтобы вам, разработчику приложения, было проще, потому что потоки ввода-вывода довольно сложно реализовать в .NET самостоятельно.

Я предполагаю, что расширение.Разработчики .NET Framework намеренно решили усложнить публикацию операций ввода-вывода (по сравнению с рабочими потоками, где вы можете просто написать ThreadPool.QueueUserWorkItem ), потому что это сравнительно «опасно», если вы не знаете, как используйте их правильно; напротив, на самом деле довольно просто создать их в Windows API .

Как и раньше, вы можете проверить, что происходит, с помощью некоторого отладочного кода:

WebRequest request;

IAsyncResult BeginDownload(object sender, EventArgs e,
    AsyncCallback cb, object state)
{
    request = WebRequest.Create("http://www.example.com");
    return request.BeginGetResponse(cb, state);
}

void EndDownload(IAsyncResult ar)
{
    int maxWorkers, maxIO, availableWorkers, availableIO;
    ThreadPool.GetMaxThreads(out maxWorkers, out maxIO);
    ThreadPool.GetAvailableThreads(out availableWorkers, out availableIO);
    string html;
    using (WebResponse response = request.EndGetResponse(ar))
    {
        using (StreamReader reader = new
            StreamReader(response.GetResponseStream()))
        {
            html = reader.ReadToEnd();
        }
    }
}

Если вы пройдете через этот код, вы увидите, что статистика потоков отличается. availableWorkers будет соответствовать maxWorkers , но availableIO на единицу меньше, чем maxIO . Это потому, что вы работаете в потоке ввода-вывода. Вот почему вы не должны выполнять какие-либо дорогостоящие вычисления в асинхронных обратных вызовах - размещение интенсивной работы ЦП на порте завершения ввода-вывода неэффективно и, в общем, плохо.

Все это объясняет, почему настоятельно рекомендуется использовать асинхронные страницы в ASP.NET, когда вам нужно выполнить какие-либо операции ввода-вывода. Шаблон только полезен для операций ввода / вывода ; Асинхронные операции, не связанные с вводом-выводом, в конечном итоге будут отправлены рабочим потокам в ThreadPool , и вы все равно будете блокировать последующие запросы ASP.NET. Но вы можете создать практически неограниченное количество операций асинхронного ввода-вывода и не задумываться об этом; они вообще не будут использовать какие-либо потоки до тех пор, пока ввод-вывод не будет завершен и обратный вызов не будет готов к началу.

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

Что касается пункта 3, то на самом деле это не вопрос «почему не запрос отключается», скорее вопрос «почему это ?» Сокет не закрывается просто потому, что в данный момент нет потока, отправляющего или получающего от него данные, точно так же, как ваша входная дверь не закрывается автоматически, если рядом нет никого, кто мог бы приветствовать гостей. Операции клиента могут истечь , если сервер не отвечает им, и впоследствии может выбрать отключение от их конца, но это уже другая проблема.

Ответ также зависит от того, о какой версии IIS вы говорите. В более ранних версиях ASP.NET не использовал «потоки IIS». Это были потоки .NET ThreadPool. В IIS 7 конвейеры IIS и ASP.NET были объединены. Я не знаю, какие потоки сейчас использует ASP.NET.

Суть в том, что не создавайте свои собственные темы.

1) Потоки находятся в w3svc или другом процессе, в котором запущен механизм ASP.NET в вашей конкретной версии IIS.

2) Не понимаю, что вы здесь имеете в виду. Фактически вы можете контролировать количество потоков в пуле рабочих потоков. Эта статья довольно хороша: http://msdn.microsoft.com/en-us/library/ms998549.aspx

3) Я думаю, вы путаете запросы и соединения ... Если честно, я не знаю Понятия не имею, как работают внутренние компоненты IIS, но обычно в приложениях, которые обрабатывают несколько запросов одновременно, есть ОДИН главный поток прослушивания, который затем передает фактическую работу дочернему потоку (и больше ничего не делает). Исходный запрос не «отключается», потому что все это происходит на совершенно разных уровнях стека сетевых протоколов. Windows Server без проблем принимает несколько подключений через TCP-порт 80. Подумайте о том, как работает TCP / IP, и о том, что он отправляет несколько отдельных пакетов информации. Вы думаете о «соединении», как об одном шланге, идущем от патрубка A к патрубку B, но, конечно, это не так, как это работает на самом деле. Это больше похоже на ведро, которое просто собирает все, что в него пролилось.

Надеюсь, это поможет.