ISAPI Extenstion and Threading

Vovka · Post by **Vovka** » 08 Oct 2003 16:44

Как обычно поступают с обработкой длительных запросов?
Вроде как напрашивается использование asynchronous I/O и thread pooling.
С другой стороны, extension (в нашем случае) живёт в dllhost.exe. А этот процесс вроде-как имеет свой thread pool. Так вот и не ясно, как быть, имеет ли смысл создание собственного thread poolа, или получится масло масленное, и свой собственный thread pool будеть только мешать?

yocto · Post by **yocto** » 08 Oct 2003 20:13

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

Vovka · Post by **Vovka** » 08 Oct 2003 21:28

yocto wrote:Свой пул обязательно нужен, поскольку основная процедура твоего extension вызывается на одном из потоков, принадлежащих IIS. Число этих потоков ограниченно, и занимать их без нужды - понижать время отклика для всей системы.

Ясно, вроде и сам сейчас до этого дочитался.

Только вот такой вопрос ещё не понял. В документации прогагандируется использование Asynchronous I/O для чтения клиента и посылке клиенту. Но что-то пока сложно после первого чтения воспринимается, тем более странно, что вроде как в каждый момент времени может быть только одна pending read or write operation

, или я что-то не так понял.
А что если вместо этого в HttpExtensionProc вызывать QueueUserWorkItem с параметром-процедурой, собственно обрабатывающей запрос, и возвращать HSE_STATUS_PENDING? А уже в этой процедуре использовать обычный - синхронный - read and write, а по завершении вызывать ServerSupportFunction c HSE_REQ_DONE_WITH_SESSION. Чем такое использование хуже Asynchronous I/O?

yocto · Post by **yocto** » 08 Oct 2003 22:24

Однозначно что-либо сказать не могу, поскольку нужна дополнительная информация. Зависит от логики работы самого extension.

ReadClient/WriteClient стоят немного особняком, так как тут используется физический канал, установленный между IIS и клиентом. Этот канал скрыт в недрах IIS и сам по себе может порождать блокировки, к разрешению которых extension module не подпускается. Как мне кажется, поделом.
Я говорил о той части обработки запроса, к которой IIS не имеет отношения и, соответственно, не может правильно ей управлять.

А вообще, стандартов поведения тут нет. Если ты ясно представляешь, что IIS отвечает только за транспорт и всё остальное - твоя забота. Чем меньше ты занимаешь потоки, управляемые самим IIS, тем лучше для всех.
Готовить ли данные к передачи целым куском или делать это по частям с постоянным возвращением STATUS_PENDING - решается применительно к каждому конкретному случаю. Например, не все клиенты могут поддерживать chunked transfer.
Лично для меня идеальный случай такой:
Прочитал входные данные - поставил их в очередь на обработку одним из своих потоков - сразу свалил.
Подготовил данные к отправке (или часть данных) - записал в канал - свалил.

Как пример можешь посмотреть исходник для Soap Toolkit 1.0. MS его распространяла с исходником для ISAPI Listener.
Там, правда, был серьёзный ляп, но не по поводу распределения запросов на обработку.