Использует ли IIS W3WP неблокирующий ввод-вывод для обслуживания статического содержимого?
Скажем так ...
IIS обслуживает статический ресурс .MP3 размером 10 МБ. Запрос ресурса поступает в HTTP.sys и отправляется соответствующему процессу W3WP для обработки. Затем рабочий процесс захватывает поток из пула для обработки этого запроса. Теперь, исходя из моего предположения, указанный поток будет привязан к вводу-выводу, пока он читает ресурс .MP3 с диска. Это точно? Каждый раз, когда поступает запрос на этот элемент, поток из пула читает одно и то же содержимое с диска? Использует ли W3WP неблокирующий ввод-вывод для получения объекта?
Далее, допустим, имеется 1000 одновременных запросов на один и тот же файл .MP3; Может ли это повлиять на сайт из-за размера по сравнению с другими запрашиваемыми ресурсами? Медлительность, очереди и т. Д.?
Это зависит от того, как вы пишете свой веб-сервис или приложение. И важно, чтобы мы договорились о том, что означает «неблокирующий» или «асинхронный» в этом контексте.
Как правило, нет, w3wp.exe не использует вызовы асинхронного ввода-вывода при извлечении файлов из хранилища для обслуживания статического содержимого. Но, конечно, это не означает, что w3wp.exe просто полностью мертв, потому что в данный момент он обслуживает файл размером 10 МБ. Каждый рабочий процесс (из которых может быть много одновременных экземпляров, работающих на сервере), каждый имеет в своем распоряжении весь пул потоков, включая потоки, выделенные для операций ввода-вывода.
Когда пользователь запрашивает статический файл из IIS через Интернет, w3wp.exe выдает IRP_MJ_CREATE (CreateFile API) для запрошенного файла. (Это может происходить с жесткого диска или из файлового кеша, но это не имеет отношения к данному вопросу.) Операция IRP_MJ_CREATE запускается с опцией «Общее чтение», которая, согласно Документация MSDN, на самом деле это набор опций:
STANDARD_RIGHTS_READ, FILE_READ_DATA, FILE_READ_ATTRIBUTES, FILE_READ_EA и СИНХРОНИЗИРОВАТЬ.
Здесь интересна опция СИНХРОНИЗАЦИЯ:
• Для вызывающей стороны для синхронизации завершения ввода-вывода, ожидая возвращенного FileHandle, должен быть установлен флаг SYNCHRONIZE. В противном случае вызывающий объект, который является устройством или промежуточным драйвером, должен синхронизировать завершение ввода-вывода с помощью объекта события.
Вы можете использовать тот же API CreateFile для асинхронного ввода-вывода, но вы можете сказать, что это не асинхронный вызов, поскольку флаг OVERLAPPED не используется.
CreateFile обеспечивает создание синхронного или асинхронного дескриптора файла или устройства. Синхронный дескриптор ведет себя так, что вызовы функций ввода-вывода с использованием этого дескриптора блокируются до их завершения, в то время как асинхронный дескриптор файла позволяет системе немедленно возвращаться из вызовов функций ввода-вывода, независимо от того, завершили ли они операцию ввода-вывода или не. Как указывалось ранее, это синхронное и асинхронное поведение определяется путем указания FILE_FLAG_OVERLAPPED в параметре dwFlagsAndAttributes.
Итак, да, тысяча пользователей, одновременно загружающих файл размером 10 МБ с вашего веб-сайта, может снизить производительность вашего сервера. Основная стратегия IIS для решения этой проблемы - использование множества потоков. Исчерпание потоков, настройка и определение размера пула потоков - это реальные вещи, о которых администраторы IIS должны знать. Если у вас действительно огромный веб-сайт, вы можете даже принять участие в игре по перемещению статического контента на отдельную ферму веб-серверов из-за ограничений ввода-вывода по сравнению с ограничениями вычислений и т. Д. Настройка производительности IIS - очень сложная тема, и этот конкретный Serverfault Ответ довольно педантичен по большому счету. Например, это является возможно использование асинхронных обработчиков в IIS. Это зависит от того, как вы пишете свой веб-сервис / приложение.