Оптимизация IIS 7.5 для сайта, обслуживающего только статический контент
Я хочу настроить домен без файлов cookie, предназначенный для размещения статического контента для веб-приложения, аналогично сайту http://sstatic.net/ который используют сайты обмена стека.
У меня вопрос, какие оптимизации я могу внести в настройки IIS 7.5 для такого домена? Например, он никогда не будет нести ответственность ни за что, кроме обслуживания статического контента, поэтому будет ли отключение интеграции ASP.NET хорошим шагом для этого сайта?
Любые предложения или рекомендации по настройке такого сайта с IIS 7.5 будут приветствоваться.
редактировать
Просто для пояснения, это не ЕДИНСТВЕННЫЙ сайт на сервере, поэтому предлагаемые оптимизации должны быть нацелены на уровень сайта, а не на конфигурацию уровня сервера.
2 ответа
В этом есть несколько соображений, некоторые из которых обрабатываются в IIS (сжатие HTTP, кэширование заголовков fx), а некоторые - во время процесса сборки / перед развертыванием (например, конкатенация Javascript и CSS-файлов и минимизация пробелов).
Таким образом, довольно сложно дать вам полное изложение в одном ответе, поскольку некоторые из них будут зависеть от ваших методов сборки и выпуска. На высоких уровнях:
Сайт не имеет файлов cookie, так как вы используете новый домен, который не привязан к вашему веб-приложению. Так как вы не устанавливаете куки для домена (используя код приложения fx.NET), тогда он "без куки".
Вы должны обязательно включить HTTP-сжатие для статического текстового содержимого, такого как Javascript и CSS.
Я не лучший администратор IIS, но, насколько я могу судить, вам нужны только компоненты IIS по умолчанию, связанные с основной ролью сервера "Веб-сервер (IIS)".
Вы должны обязательно включить длинные заголовки кэширования для статического контента. Общая рекомендация - 31 день, но вы можете установить ее выше или ниже. Помните, что если вы используете статический контент с длинными заголовками кэша, то вы должны изменить URL-адрес, если вы измените файл, чтобы клиенты не могли повторно использовать старый кэшированный контент.
Вы должны включить HTTP keep-alive (те же документы, что и для кэширования заголовков).
В дополнение к этому, есть задачи перед развертыванием, такие как сжатие пробелов в Javascript и CSS, и, в идеале, лучшее сжатие PNG и т. Д. Это были ваши инструменты разработки, и цикл сборки помогает решить, как действовать дальше.
Когда вы закончите, попробуйте загрузить несколько файлов со статических серверов с включенной YSlow. Я считаю, что набор правил "Classic V2" оказывает наибольшее влияние на усилия, поэтому я бы посоветовал сравнить ваш счет с этим набором правил YSlow.
Из набора правил "Classic V2" эти правила применяются исключительно к экземплярам и содержимому IIS статического сервера:
3. Add an Expires or a Cache-Control Header
4. Gzip Components
10. Minify JavaScript and CSS
11. Avoid Redirects
13. Configure ETags
19. Use Cookie-Free Domains for Components
22. Make favicon.ico Small and Cacheable
Здесь очень интересно написать, где кто-то использует IIS для обслуживания статических файлов. Основное внимание уделяется настройке параметров кэширования файлов IIS для ограничения дисковой активности (что было его узким местом). Он говорит, что видел увеличение производительности в 20 раз.