Мы запускаем виртуальную машину Windows 2012R2 с IIS 8.5 с целью обслуживания плоских файлов, при этом не используется ни ASP.NET, ни другое динамическое содержимое. Сервер настроен для сопоставления 5 сайтов с одним и тем же IP-адресом и фильтрацией портов по полному доменному имени и обслуживает только файлы HTML, JS и CSS на этих сайтах. По большей части файлы поступают из виртуальных каталогов, которые сопоставлены с локальными папками, однако я замечаю, что время от времени файлы загружаются произвольно медленно. Мое подробное тестирование проводилось в Chrome, хотя я видел аналогичную "случайную" медлительность в Firefox и IE.
В соответствии с конфигурацией, большинство значений по умолчанию остаются на месте. У каждого сайта есть свой собственный пул приложений, и все они имеют конфигурации по умолчанию, а поскольку ASP.NET не установлен, параметры довольно простые для того, что даже доступно. После некоторого поиска я включил кэширование вывода в пользовательском режиме и в режиме ядра, настроенном на использование «уведомлений об изменении файлов», а сжатие было включено по умолчанию для статического и динамического содержимого.
Медлительность возникает при загрузке сайтов, при запуске загружается ~ 54 файла. По разным причинам большинство из них не будут объединены, но в будущем некоторые из них могут быть объединены, однако время от времени IIS зависает при доставке одного из файлов. Файл размером 100 КБ будет доставлен за несколько миллисекунд, а затем файл размером 50 КБ будет доставлен в течение 9 секунд. В других случаях все файлы загружаются менее чем за 10 мс. Обратите внимание, что это тестирование проводилось с отключенным кешем Chrome для тестирования времени.
В целом я парень, работающий с Unix, и подозреваю, что ответ на мои проблемы заключается в использовании NGINX, который, по моему личному мнению, лучше подходит для этой задачи, но я считаю, что это личное предубеждение, и хотел протянуть руку, чтобы увидеть если бы были другие возможности, которых я упускал. Большинство мест, где решаются проблемы производительности с помощью IIS, похоже, сосредоточены вокруг приложений ASP.NET, а не доставки плоских файлов. Опять же, может быть, это наша проблема, хе.
Это сервер с выходом в Интернет или сервер с выходом в интрасеть? Я бы сам не прочь взглянуть на это.
Теоретически не должно быть никаких причин, по которым IIS медленно обслуживает статический контент - все они маршрутизируются через обработчик статических файлов, что чрезвычайно эффективно.
Вы можете попробовать:
Убедитесь, что веб-сайты никогда не простаивают (в результате рабочий процесс IIS завершает работу - каждый пул приложений получает свой собственный двоичный процесс в памяти, w3wp.exe, к которому httpd отключается после разрешения привязки - поэтому есть некоторая задержка в 10 секунд или около того, чтобы перезапустить этот процесс, если он выключен) - вы можете сделать это, изменив параметр запуска пулов приложений с «по запросу» на «всегда включен».
Переключите пул приложений на «без управляемого кода» - это изменяет модель конвейера и гарантирует, что запросы в любом случае не будут проходить через механизм asp.net.
Если сервер никогда не будет размещать какие-либо веб-сайты asp.net, вы можете подумать об отключении этих функций (их удалении). То же самое для динамического сжатия - вы можете удалить это, если сервер никогда не будет запускать asp.net.
Как там дисковый ввод-вывод? Если IIS отслеживает изменения файлов и перезагружает их в кеш, возможно, проверка каждой контрольной суммы файла занимает некоторое время из-за плохого ввода-вывода на диске. Вы используете ESX или HyperV для визуализации? Способ, которым хранилище данных было представлено серверу (локальный диск против SAN), может повлиять, сетевой диск будет иметь более медленный ввод-вывод. Хотя это, вероятно, последний перезапуск, я уверен, что плохой дисковый ввод-вывод сначала проявится и другими заметными способами.
Откажитесь и сбросьте свой контент в корзину S3, а затем отправьте его с помощью распространения Cloudfront CDN. :) Просто скажи.
Я устранял ту же проблему и, похоже, проблема в IIS 8.5, когда включены как динамическое, так и статическое сжатие. Та же проблема не обнаруживается в IIS 10.0 (в моих тестах).
Вы можете применить один из следующих обходных путей:
Отключить динамическое сжатие для папки со статическими файлами (добавить в system.webServer в web.config):
<urlCompression doDynamicCompression="false" />
Отключить проверку частоты обращений (на уровне сервера для IIS 8.5)
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /staticCompressionIgnoreHitFrequency:"True" /commit:apphost
Настройте проверку частоты совпадений, используя этот ответ.
Внедрите один из способов обхода, и вы увидите огромное улучшение скорости ответа / загрузки.