ASP.NET: легитимная архитектура / HttpModule относится? - PullRequest
2 голосов
/ 18 ноября 2009

Архитектор моей работы недавно прочитал Руководство по исключительной производительности Yahoo! , в котором говорится об использовании заголовка Expires далекого будущего для ресурсов, используемых страницей, таких как JavaScript, CSS и изображения , Идея состоит в том, что вы устанавливаете заголовок Expires для этих ресурсов на годы вперед, чтобы они всегда кэшировались браузером, и всякий раз, когда мы меняем файл и, следовательно, нуждаемся в браузере, чтобы запросить ресурс снова вместо использования его кэша, измените имя файла добавив номер версии.

Вместо того, чтобы включить это в наш процесс сборки, у него есть другая идея. Вместо того, чтобы менять имена файлов в источнике и на диске сервера для каждой сборки (да, это было бы утомительно), мы собираемся подделать его. Его план состоит в том, чтобы установить истекшее будущее на указанных ресурсах, а затем внедрить два модуля HttpModules.

Один модуль будет перехватывать все потоки ответов наших страниц ASPX и HTML, прежде чем они выйдут, ищут ссылки на ресурсы и привязывают параметр версии, который является датой последнего изменения файла. Другой HttpModule будет обрабатывать все запросы на ресурсы и просто игнорировать часть версии адреса. Таким образом, браузер всегда запрашивает новый файл ресурсов каждый раз, когда он изменяется на диске, без необходимости изменять имя файла на диске.

Имеет смысл?

Моя проблема связана с модулем, который переписывает поток ответа ASPX / HTML-страницы. Он просто собирается применить набор Regex.Replace () к атрибутам "src" тегов <script> и <img> и атрибуту "href" тегов <link>. Это будет происходить для каждого отдельного запроса на сервере с типом контента «text / html». Потенциально сотни или тысячи в минуту.

Я понимаю, что модули HttpModules подключены к конвейеру IIS, но это должно добавить непомерную задержку во времени, которое требуется IIS для отправки HTTP-ответов. Нет? Что ты думаешь?

Ответы [ 3 ]

1 голос
/ 18 ноября 2009

Несколько вещей, которые нужно знать:

  1. Если идея заключается в добавлении строки запроса к статическим именам файлов для указания их версии, к сожалению, это также предотвратит кэширование драйвером HTTP режима ядра (http.sys)
  2. Сканирование каждого полного ответа на основе набора регулярных выражений будет медленным, медленным, медленным. Это также может быть ненадежным, с трудно предсказуемыми угловыми случаями.

Несколько альтернатив:

  1. Используйте адаптеры управления для явной замены определенных URL или путей текущей версией. Это позволяет вам сосредоточиться на изображениях, CSS и т. Д.
  2. Менять имена папок вместо имен файлов при версии статических файлов
  3. Рассмотрите возможность использования скинов ASP.NET для централизации имен файлов. Это поможет упростить обслуживание.

Если это полезно, я освещаю эту тему в своей книге ( Ultra-Fast ASP.NET ), включая примеры кода.

0 голосов
/ 18 февраля 2010

http://code.google.com/p/talifun-web

StaticFileHandler - Служить статическим файлам кэшируемым, возобновляемым способом. CrusherModule - обслуживать сжатые версии JS и CSS кэшируемым способом.

Вы не совсем получаете скорость кэширования в режиме ядра, но обслуживание от HttpRuntime.Cache имеет свои преимущества. Кэш режима ядра не может кэшировать частичные ответы, и у вас нет точного контроля над кешем. Наиболее важная вещь для реализации - это согласованный заголовок etag и заголовок expires. Это улучшит производительность вашего сайта больше всего на свете.

Сокращение количества обслуживаемых файлов, вероятно, является одним из лучших способов повысить скорость вашего сайта. CrusherModule объединяет все CSS на вашем сайте в один файл и все JS в другой файл.

Память дешевая, жесткие диски медленные, так что пользуйтесь!

0 голосов
/ 18 ноября 2009

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

Что касается модулей HTTP - в принципе, я бы сказал, что они в порядке, но вы захотите, чтобы они были ослепительно быстрыми и эффективными, если вы пойдете по этому пути; наверное стоит попробовать. Я не могу говорить о целесообразности использования RegEx, чтобы делать то, что вы хотите сделать внутри.

Если вы ищете высокую производительность, я предлагаю вам (или вашему архитектору) немного почитать (и я не имею в виду это противным образом). Недавно я узнал кое-что, что, я думаю, поможет - позвольте мне объяснить (и, возможно, вы, ребята, уже знаете это).

Браузеры одновременно поддерживают только ограниченное количество одновременных подключений к определенному имени хоста. например, IE6 сделает 6 подключений, чтобы сказать www.foo.net.

Если вы позвоните своим изображениям, скажем, с images.foo.net, вы сразу получите 6 новых соединений. Идея состоит в том, чтобы разделить разные типы контента на разные имена хостов (css.foo.net, scripts.foo.net, ajaxcalls.foo.net), чтобы убедиться, что браузер действительно работает от вашего имени.

...