Назад | Перейти на главную страницу

Оптимизация IIS 7.5 для сайта, обслуживающего только статический контент

Я хочу настроить домен без файлов cookie, предназначенный для обслуживания статического контента для веб-приложения, аналогичный http://sstatic.net/ сайт, который используют сайты обмена стеками.

У меня вопрос: какие оптимизации я могу внести в настройку IIS 7.5 для такого домена? Например, он никогда не будет отвечать ни за что, кроме обслуживания статического контента, поэтому будет ли отключение интеграции ASP.NET хорошим шагом для этого сайта?

Приветствуются любые предложения или ссылки по созданию такого сайта с IIS 7.5.

редактировать

Чтобы уточнить, это не ЕДИНСТВЕННЫЙ сайт на сервере, поэтому предлагаемые оптимизации должны быть нацелены на уровень сайта, а не на конфигурацию уровня сервера.

В этом есть несколько соображений, некоторые из которых обрабатываются в IIS (сжатие HTTP, кэширование заголовков fx), а некоторые обрабатываются во время процесса сборки / перед развертыванием (например, Javascript и объединение файлов CSS и минимизация пробелов).

Таким образом, немного сложно дать вам полное изложение в одном ответе, так как некоторые из них будут зависеть от ваших методов сборки и выпуска. На шагах высокого уровня:

  • Сайт не поддерживает файлы cookie, поскольку вы используете новый домен, который не привязан к вашему веб-приложению. Поскольку вы не устанавливаете файлы cookie для домена (используя код приложения f.x. .NET), тогда он будет «без файлов cookie».

  • Вам следует абсолютно включить 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-кратное увеличение производительности.