none
Асинхронная обработка запросов в ASP.net RRS feed

  • Вопрос

  • Всем привет!

    Информации по этой теме много, например, тут. Хотелось бы спросить вот какие моменты.

    1. При обработке асинхронно своего хэндлера реализующего  IHttpAsyncHandler, мы можем вызвать асинхронно обработчик вызвовом  BeginProcessRequest. Хорошо, но фактически обработка происходит при помощи Task, при этом выделяется поток для обработки из пула рабочих потоков. Но мне стало интересно, ведь асинхронную обработку страниц специально для этого и придумывали, чтобы не занимать потоки из пула, чтобы они могли обрабатывать запросы, которые поступают на сервер. Или я сам что-то недопонимаю, ведь пул потока в asp.net общий как и для запросов, так и для заданий (Task).

    2. Судя по той же статье, 

    видно, что после того как запущена асинхронная операция, первый поток возвращается в пул, а после обработки асинхронной операции вытаскивается для дальнейшей обработки HTTP конвейера другой поток из пула. Как это происходит более подробно? Смотрел через декомпилятор (.NET reflector или ILSpy), вся обработка асинхронная заточена под Task, мне интересно каким образом поток возвращается в пул? и как потом другой поток может продолжить работу, ведь чтобы продолжить, надо хотя бы воссоздать тот самый стек, которым пользовался 1-ый поток.

    12 апреля 2014 г. 10:32

Ответы

  • "Но мне стало интересно, ведь асинхронную обработку страниц специально для этого и придумывали, чтобы не занимать потоки из пула, чтобы они могли обрабатывать запросы, которые поступают на сервер." - да именно так. В целом мы делим условно запросы на два типа: те которые требуют вычислительных мощностей процессора и те которые просто требуют ввода/вывода. В первом случае от асинхронности нет никакого толка, один только вред. Но всё дело в том, что в вебе 95% запросв нуждаются только во вводе и выводе. Вот тут то мы и получаем выигрыш от асинхронности. Так как в этом случае потоки не используются для ожидания ввода/вывода, а используются ресырсы Windows, так называемые I/O Completion Ports. Получается, поток на некоторое время освобождается и готов обработать другой запрос. И ещё один важный момент. Если у нас количество запросов не много, то и тут нет толка от асинхронности. Если много, получаем сильный выигрыш в производительности.

    "Как это происходит более подробно? Смотрел через декомпилятор (.NET reflector или ILSpy), вся обработка асинхронная заточена под Task, мне интересно каким образом поток возвращается в пул?" - а вот на эти вопросы, вы найдёте ответы в книге Рихтера, глава 28.


    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 13 апреля 2014 г. 5:57
    12 апреля 2014 г. 13:26
    Модератор

Все ответы

  • "Но мне стало интересно, ведь асинхронную обработку страниц специально для этого и придумывали, чтобы не занимать потоки из пула, чтобы они могли обрабатывать запросы, которые поступают на сервер." - да именно так. В целом мы делим условно запросы на два типа: те которые требуют вычислительных мощностей процессора и те которые просто требуют ввода/вывода. В первом случае от асинхронности нет никакого толка, один только вред. Но всё дело в том, что в вебе 95% запросв нуждаются только во вводе и выводе. Вот тут то мы и получаем выигрыш от асинхронности. Так как в этом случае потоки не используются для ожидания ввода/вывода, а используются ресырсы Windows, так называемые I/O Completion Ports. Получается, поток на некоторое время освобождается и готов обработать другой запрос. И ещё один важный момент. Если у нас количество запросов не много, то и тут нет толка от асинхронности. Если много, получаем сильный выигрыш в производительности.

    "Как это происходит более подробно? Смотрел через декомпилятор (.NET reflector или ILSpy), вся обработка асинхронная заточена под Task, мне интересно каким образом поток возвращается в пул?" - а вот на эти вопросы, вы найдёте ответы в книге Рихтера, глава 28.


    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 13 апреля 2014 г. 5:57
    12 апреля 2014 г. 13:26
    Модератор
  • 1000 благодарностей
    13 апреля 2014 г. 5:56
  • Рад помочь :)

    Сделаем содержимое сообщества лучше, вместе!

    13 апреля 2014 г. 6:21
    Модератор