Асинхронные контроллеры

Не совсем понимаю как работают асинхронные контроллеры в ASP.NET MVC.
Допустим есть два action method-а. Один синхронный второй асинхронный.
Веб-сервер поддерживает пул потоков, которые обслуживают запросы. Когда пользователь обращается к веб-ресурсу, веб-сервер выделяет поток из пула для обслуживания данного запроса. И пока данный поток не обработает предназначенный для него запрос, другие запросы он обрабатывать не может.
Запрос к db.Books сам по себе может занять некоторое время.
1 случай: При синхронной обработке запроса поток, обрабатывающий запрос, временно блокируется, пока БД не вернет нужные нам данные. И если обработка запроса блокируется очень долго, то IIS начинает задействовать для обслуживания других входящих запросов новые потоки.
2 случай: При асинхронной обработке поток не ждет, пока БД вернет ему данные, а обрабатывает запрос от другого пользователя. Но когда, наконец, с БД придут нужные данные, поток возвращается к обработке ранее обрабатываемого запроса в обычном режиме.

Вопрос: В первом случае, если поток на долго блокируется, IIS создаст второй поток для обслуживания новых запросов (2 потока). Во втором случае тоже создается второй поток Task.Run(() => db.Books);. Если в обоих случаях создаются два потока то в чем разница?
Или пул потоков CLR и пул потоков IIS это два абсолютно разных пула?

0

Сообщение от AsusKV В первом случае, если поток на долго блокируется, IIS создаст второй поток для обслуживания новых запросов (2 потока).

не создает, а берет готовый свободный из очереди пула потоков (в этом и суть пула готовых созданых потоков, по сути это смысл любой реализации патерна object pool)

Сообщение от AsusKV Во втором случае тоже создается второй поток Task.Run(() => db.Books);. Если в обоих случаях создаются два потока то в чем разница?

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

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

Добавлено через 1 минуту

Сообщение от AsusKV Или пул потоков CLR и пул потоков IIS это два абсолютно разных пула?

это разные вещи

0

То есть, если я правильно понял, при асинхронной операции происходит следующее. IIS выделяет поток именно из пула робочих потоков для выполнения action method-а контроллера. Именно этот поток заходит в action method и начинает его выполнение. Когда он доходит до строчки , то поток выделяется уже из пула потоков CLR. При этом поток, который выполнял action method до этой строчки возвращается в пул рабочих потоков IIS и может быть использован для обработки других запросов пользователя. Я все правильно понял? Если да, тогда второй вопрос. Когда чтение из базы выполнится и action method сможет продолжить работу, для его продолжения выделится любой первый доступный поток из пула рабочих потоков IIS?

0

ToListAsync
http://www.codeproject.com/Tip... SP-NET-MVC

0

Может быть я просто не понимаю чем занимается пул потоков clr, а чем пул потоков iis. Любой метод контроллера выполняет пул потоков слр, а не иис, правильно? Тогда в первом случае выполнением задачи занимается скажем поток номер 3. А во втором ми просто говорим, поток номер 3 нам не нравится, забирайте его обратно и дайте нам какойто другой из пула слр? В чем выгода? Или если этот екшин метод имеет ключевое слово асинк то как то по другому на это реагирует пул потоков иис? Какой тогда workflow?

Добавлено через 12 минут
Пользователь отравляет запрос, http.sys listener его ловит, потом выделяется поток из пула iis? На каком этапе тогда появляется поток из пула clr? Пока clr поток не обработает екшин метод, то поток из пула iis будет ждать ответ? Или в случае если метод с ключевым словом асинк то поток из пула иис не ожидает? Какой поток тогда обработает ответ от слр?

0

Здесь проблема не в потоках, а том что метод не ждет получения ответа от базы и отдает поток сразу. При получении ответа от базы выбирается новый поток и задача продолжается уже в новом потоке с места await .
await по сути это автомат, такой же как и yield

0

Поток отдается сразу... в этом и мой вопрос, который это поток iis илu clr? Екшин метод выполняется потоком из пула слр. Правильно ли я понимаю, разсудите плз. Пользователь отправляет запрос, хттп.сус драйвер его ловит, выделяется поток из пула потоков иис, потом запускается поток из пула слр и именно он выполняет код екшин метода. В первом случае поток из пула иис ожидает завершение работы потока из пула слр, во втором случае поток из пула слр запускает поток номер два а сам возвращает управление потоку иис, а тот возвращается в пул иис. А когда поток номер два завершит работу то он же продолжит выполнять все что после await а потом отдаст ответ в порт завершения ввода вывода?

0

Пул потоков для CLR отдельно, для натива отдельна. Ты можешь отдельно настроить приложение какой пул IIS будешь использовать. http://metanit.com/sharp/articles/mvc/10.php

0

Правильно ли я понимаю pipeline?:
- пришел запрос от пользователя, iis выделил поток (назовем поток 1) для обработки запроса
- выделяется поток из пула clr (поток 2), Для обработки кода екшин метода
При синхронном поток 1 ожидает ответ от потока 2.
При асинхронном:
- поток 2 порождает асинхронную операцию, и возвращает управление, поток 1 возвращается в пул потоков iis и может обрабатывать другие запросы.
- когда асинхронная операция вернет результат, достанется поток из пула потоков clr(поток 3), обработает весь код после await, вернет управление
- из пула потоков iis достанется поток 4 который и отправит результат пользователю.

Ссылка на metanit меня еще больше запутала Я не понимаю что делают потоки из пула iis, а что делают потоки из пула clr, кто за что отвечает? На каком этапе поток из пула iis передает работу потоку из пула clr, а когда потом обратно? Какой поток когда возвращает управление? Пожалуйста обьясните

0

это тема веселая, я помню часа три просидел на stackoverflow пытаясь понять в чем смысл )

всё очень просто - в асинхронном поток освобождается и может обрабатывать другие соединения, в этом весь смысл, ибо количество потоков ограниченно

а во вторых Async != отдельный поток
в глубинах винды есть своя специальная асинхронность на уровне прерываний, не помню как называется, неблокирующий или overlapped что-то там
вот короче эта штуковина умеет не блокировать поток, не создавая при этом отдельный поток для некоторых случаев, для файлов точно есть, для сетевых операций тоже, может даже для БД что-то придумали

меня так протроллили на собеседовании однажды, я бил пяткой в грудь что умею в потоки, а спросили как ngnix работая в 1 поток обрабатывает несметные тысячи соединений, вот так и работает(как и другие веб серверы)..

0

Сам не до конца понимаю, интересно стало, видимо ТС имел ввиду такой момент: один IO-поток из пула потоков IIS
принимает конкретный запрос и сплавляет, то есть ставит задачу в очередь задач пула потоков. Тут более менее понятно, в подтверждение http://blogs.msdn.com/b/tmarq/... d-6-0.aspx:

When ASP.NET is hosted on IIS 6.0, the request is handed over to ASP.NET on an IIS I/O thread. ASP.NET immediately posts the request to the CLR ThreadPool and returns HSE_STATUS_PENDING to IIS. This frees up IIS threads, enabling IIS to serve other requests, such as static files. Posting the request to the CLR Threadpool also acts as a queue

То есть, как понял, IIS-потоки выполняют пограничную работу - прием соединения и возвращения результата, причем все это делается драйвером уровня ядра http.sys. Сама же обработка выполняется приложением в пользовательском режиме потоком из пула CLR. И вот тут нюанс непонятный мне, и, видимо, ТС-у тоже:

1. В случае синхронной обработки (без async), метод действия выполняется в потоке пула до его завершения, даже
если в коде идут какие-то долговременные IO-операции (запрос к базе и т.д.).
2. В случае асинхронной обработки из пула потоков берется какой-то свободный поток и в нем начинает выполняться метод. Поскольку метод async, то он сразу возвращает управление, то есть взятый поток снова возвращается в пул, при этом за счет использования Task-ов саму долговременную IO-операцию уже другой поток, причем тоже из пула потоков CLR.
То есть плюс использования асинхронности в том, что потоки пула быстрее освобождаются и ,как следствие, меньше простаивают, и у нас появляется возможность ставить больше задач обработки запросов в единицу времени, хотя сам CLR-пул более интенсивно используется. Так, не?
И все же в таком случае потоки пула могу быстрее закончиться, не? )
И как контраргумент в пользу синхронной обработки: даже если поток пула будет выполнять долговременную IO-операцию, то в случае появления новых запросов с таким же успехом мы просто возьмем еще один поток из пула CLR для обработки, поскольку в этом случае пул не так интенсивно используется, и он там сто пудово будет.
pS: надо будет прошерстить всю эту тему

0