Каталог расширений

Популярные теги

3gp       avi       fb2       jpg       mp3       pdf      

Главная » Разное » Кэширование статических файлов как включить

Кэширование статических файлов как включить


Настройка сжатия и кэширования через .htaccess

В панелях управления Plesk и cPanel сжатие и кэширование для статических файлов настраивается через .htaccess. Для настройки кэширования используется модуль expires.

Mod_expires — модуль, который подсказывает вашему браузеру, какие статические файлы нужно кэшировать. Время хранения данных в кэше можно устанавливать в следующих значениях:

  • years,
  • months,
  • weeks,
  • days,
  • hours,
  • minutes,
  • seconds.

Настройка кэширования

Настройка expires:

  1. 1. Для настройки кэширования сайта .htaccess файл должен находиться в корневой директории вашего сайта. Если у вас нет этого файла воспользуйтесь справкой: У меня нет файла .htaccess, что делать?.
  2. 2.

    Добавьте в файл .htaccess строки следующего вида:

    Mod_expires

     <ifModule mod_expires.c> ExpiresActive On #кэшировать флэш и изображения на одну неделю ExpiresByType image/x-icon "access plus 7 days" ExpiresByType image/jpeg "access plus 7 days" ExpiresByType image/png "access plus 7 days" ExpiresByType image/gif "access plus 7 days" ExpiresByType application/x-shockwave-flash "access plus 7 days" #кэшировать css, javascript и текстовые файлы на одну неделю ExpiresByType text/css "access plus 7 days" ExpiresByType text/javascript "access plus 7 days" ExpiresByType application/javascript "access plus 7 days" ExpiresByType application/x-javascript "access plus 7 days" #кэшировать html и htm файлы на один день ExpiresByType text/html "access plus 1 day" #кэшировать xml файлы на десять минут ExpiresByType application/xhtml+xml "access plus 10 minutes" </ifModule>

    Совет

    Не обязательно кэшировать все указанные виды статических файлов, укажите только те, которые есть на вашем сайте. В качестве примера указано оптимальное время хранения 7 дней, но вы можете установить эти значения самостоятельно.

Настройка сжатия

На серверах виртуального хостинга сжатие .htaccess для статических файлов включено по умолчанию. Статические файлы обрабатываются веб-сервером Nginx, доступа к настройке которого нет.

Проверить наличие сжатия можно при помощи ресурса.

Если вам критична настройка сжатия, рекомендуем приобрести VPS сервер.

Не работает кэширование .htaccess

Если после указанных настроек кэширование .htaccess не работает или у вас возникли сложности, обратитесь в техническую поддержку.

Облачные серверы нового поколения

Виртуализация KVM, почасовая оплата, резервные копии, готовые шаблоны, 10 доступных ОС на выбор!

Подробнее Помогла ли вам статья?

32 раза уже
помогла

Кэширование статических файлов сайта через htaccess

Так как скорость загрузки файлов отражается на продвижении, то уместно применять кэширование даже статических файлов и в данном случае, это будет происходить через служебный файл htaccess

Отметьте файлы, а вернее впишите их расширение, чтобы работать именно с ними и в кэш помещать именно их

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

В данном случае мы используем модуль Header веб-сервера Apache и задаем:

  • max-age - время жизни кэшированных файлов, после которого будет происходить повторная загрузка файлов.

Используется конструкция filesMatch и получаемый от сервера заголовок CacheControl. Заголовок Header позволяет контролировать http запросы и ответы сервера. И теперь один раз скачав файлы, в следующий раз компьютер клиента уже не будет их грузить (а только через время max-age) - за счет этого и достигается увеличение в скорости загрузки страницы.

Для динамических страниц со сценариями, типа php - обычно отключают кэширование. Делаем это так, добавляем ниже конструкцию вида:

<FilesMatch ".(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>

 

Кэширование статичных страниц на стороне браузера - expires модуль

Мы можем закешировать страницы сайта с помощью модуля expires. Это возможность контролировать http заголовки на стороне браузера, с возможностью задавать время жизни кэша. Также работаем с файлов htaccess:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 month"

ExpiresByType image/gif "access plus 2 months"
ExpiresByType image/jpeg "access plus 2 months"
</IfModule>

Тут мы активируем модуль, затем задаем время жизни кэша по умолчанию, а затем конкретно - для конкретных файлов, а именно для gif-файлов - 2 месяца и столько же для jpeg-файлов. Указывайте время в секундах, минутах, часах, днях, неделях, месяцах или даже годах - не возбраняется).

Какие еще файлы или mime-type точнее можно указать: image/x-icon image/jpeg image/png image/gif application/x-shockwave-flash text/css text/javascript application/javascript application/x-javascript text/html application/xhtml+xml

Теперь у вас уже явно не возникнет вопроса: Как кэшировать статические файлы сайта?)

 

Добавить комментарий

Включаем сжатие текста и кэширование статических файлов на хостинге Ru-Center

Я думаю, что все уже имеют представление об PageSpeed Insights – сервисе от Google, который показывает реальную скорость вашего сайта на различных устройствах и дает рекомендации по решению возможных проблем на нем.

Одними из популярных проблем, которые появляются в этом сервисе при проверке сайта (не только на хостинге Ru-Center) являются следующие:

Задайте правила эффективного использования кэша для статических объектов

и:

Включите сжатие текста

Каждое из таких сообщений сопровождается списком файлов, которые и создают описанные проблемы.

Исправляя эти ошибки, вы позволяете повысить оценку сервиса PageSpeed Insights (на момент написания статьи общее состояние сайта оценивается по 100-балльной шкале), ускорить загрузку вашего сайта и (если у вас много статических файлов) сэкономить интернет-трафик ваших пользователей.

Как именно исправить эти ошибки на хостинге Ru-Center так, чтобы PageSpeed Insights на них больше не «ругался», сегодня и пойдет речь.

Как включить сжатие текста и кэширование статических файлов на хостинге Ru-Center?

Обе процедуры (сжатие текста и кэширование статики) проделываются по одной схеме, меняется лишь небольшая часть кода.

1. Авторизуйтесь в панели управления хостингом.

2. Далее в левом меню перейдите в раздел «Сайты».

3. На открывшейся странице найдите домен вашего сайта и кликните по нему один раз левой кнопкой мыши.

4. На открывшейся странице, в верхней ее части перейдите в разделы «Настройки» - «Веб-сервер».

5. На открывшейся странице снимите флажок с пункта «Автоматический режим работы сайта» и нажмите кнопку «Сохранить».

6. Затем в левом меню перейдите в раздел «Файловый менеджер».

7. В нем перейдите по пути /home/pandoge/etc/nginx/sites-enabled/, где «pandoge» – логин вашего аккаунта. После чего откройте файл www.pandoge.com.site.conf одним нажатием на него название левой копкой мыши. «www.pandoge.com» в названии файла – это домен сайта, для которого мы делаем настройку и который мы ранее перевели в ручной режим работы (пункт 5).

8. В нем для настройки сжатия текста найдите строку, похожую на:

server_name pandoge.com www.pandoge.com;

и сразу после нее вставьте:

gzip_static on;
 gzip on;
 gzip_buffers 16 8k;
 gzip_comp_level 2; 
 gzip_min_length 1024; 
 gzip_types text/css text/plain text/json text/x-js text/javascript text/xml application/json application/x-javascript application/xml application/xml+rss application/javascript;
 gzip_disable "msie6";
 gzip_vary on;
 gzip_http_version 1.0;

«pandoge.com» в первом случае – это домен вашего сайта.

9. Здесь же для включения кэширования статических файлов найдите строку, похожую на:

location ~* ^.+\.(jpg|jpeg|gif|swf|png|ico|mp3|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|dat|avi|ppt|txt|tar|mid|midi|wav|bmp|rtf|wmv|mpeg|mpg|mp4|m4a|spx|ogx|ogv|oga|webm|weba|ogg|tbz|js|7z)$ {

Рядом с ней найдите строку, похожую на:

expires 720h;

и замените ее значение на «6M».

expires 6M;

Если такой строки у вас нет – просто добавьте ее.

После чего нажмите «Сохранить».

10. Далее в левом меню перейдите в раздел «Управление веб-сервером».

11. На открывшейся странице нажмите «Перезагрузить», после чего подождите, пока пропадет индикатор загрузки.

После всех этих шагов можете проверить свой сайт в PageSpeed Insights – ошибки должны исчезнуть. Если этого не произошло – напишите в комментариях, постараюсь вам помочь.

Обратите внимание, что кэширование файлов и сжатие текста не работает для внешних файлов. Подробнее об этом написано в отдельной нашей статье.

Настройка времени кеширования статических файлов — База знаний JustHost.ru

Стандартные параметры кеширования на хостинге

Для следующих MIME-типов установлен период кеширования 7 дней:

  • image/*
  • text/css
  • application/x-javascript
  • application/javascript

Для остальных типов — кеширование отключено. Переопределить параметры можно через файл .htaccess.

Пример файла .htaccess

<IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access 1 day" ExpiresByType text/javascript "access 2 day" ExpiresByType image/jpeg "access 3 day" <Files style.css> Header set Cache-Control "max-age=3600" </Files> </IfModule>

Здесь для всех типов файлов устанавливается период кеширования 1 день. Для типа text/javascript — 2 дня, для image/jpeg — 3 дня. Для файла style.css — 1 час.

В ExpiresByType можно указать любой MIME-тип.

Примеры использования директивы ExpiresByType

ExpiresByType text/cache-manifest       "access plus 0 seconds" ExpiresByType text/html                 "access plus 0 seconds" ExpiresByType text/xml                  "access plus 0 seconds" ExpiresByType application/xml           "access plus 0 seconds" ExpiresByType application/json          "access plus 0 seconds" ExpiresByType application/rss+xml       "access plus 1 hour" ExpiresByType application/atom+xml      "access plus 1 hour" ExpiresByType image/x-icon              "access plus 1 week" ExpiresByType image/gif                 "access plus 1 day" ExpiresByType image/png                 "access plus 1 day" ExpiresByType image/jpeg                "access plus 1 day" ExpiresByType video/ogg                 "access plus 1 day" ExpiresByType audio/ogg                 "access plus 1 day" ExpiresByType video/mp4                 "access plus 1 day" ExpiresByType video/webm                "access plus 1 day" ExpiresByType text/x-component          "access plus 1 day" ExpiresByType application/x-font-ttf    "access plus 1 day" ExpiresByType font/opentype             "access plus 1 day" ExpiresByType application/x-font-woff   "access plus 1 day" ExpiresByType application/x-font-woff2  "access plus 1 day" ExpiresByType image/svg+xml             "access plus 1 day" ExpiresByType application/vnd.ms-fontobject "access plus 1 day" ExpiresByType text/css                  "access plus 1 hour" ExpiresByType application/javascript    "access plus 1 hour" ExpiresByType application/x-javascript    "access plus 1 hour"

Описание параметров

Expires Default

Параметр ExpiresDefault устанавливает время кеширования по умолчанию. Если параметры кеширования уже установлены на сервере или определены на уровне виртуального хоста (.htaccess), то ExpireDefault будет переопределен.

Expires By Type

Параметр ExpiresByType устанавливает время кеширования для конкретного MIME-типа.

Пример конфигурации Nginx для контроля Expires

Сервера Nginx имеют другой формат данных и не используют файл .htaccess

server { #... location ~* \.(gif|ico|jpe?g|png)(\?[0-9]+)?$ { expires 1w; } location ~* \.(css|js)$ { expires 1d; } #... }

Поделиться ссылкой:

Похожее

Кешируем статику / Хабр

Существует мнение, что nginx — отличный инструмент для отдачи статики.
Есть статьи, где описываются настройки sendfile или aio для «улучшения» отдачи.
На Хабре есть чего почитать о настройке proxy_store с proxy_cache для минимизации проблем со стороны мозгов сайта.
Еще в QA иногда возникают вопросы про кеширование картинок, например.
Зачем заниматься этой ерундой! — говорят опытные пользователи — OS лучше вас знает как кешировать файлы! С кешем и префетчем в современных OS, точнее FS, проблем нет! Зачем плодить свои кеши и списки популярных материалов и все такое?...

Есть только одно вредное «но» — в среде исполнения nginx (в общем случае Linux) понятие "файл" и вообще «файловая система» — просто понятие.
И однажды, когда я, подмонтировав сервер по sshfs, обновил один скриптик, случилось волшебное:
1. На каждой страничке стало на 4 картинки больше.
2. Сервера сдохли.
Что поделать — картинки хранились на glusterFS. Наступил полный FUSE.

GlusterFS, как и интерфейс FUSE, сильно сжирает производительность, но он того стоит.
Изначально у нас был один сервер. Потом два, второй из который монтировал www с первого по nfs. Потом три, четыре.
Не очень надежно, но так уж исторически сложилось. Для спасения ситуации нужна была некая совершенно прозрачная система, in-place замена nfs. Кластерная ФС.
Сейчас на всех серверах стоит raid 10, и за полтора года эксплуатации он пару раз падал. В том числе совсем. Gluster молча поднимал копию ФС на новой железяке и все продолжало работать. Гластер свою работу знает.
Но на самом деле история начиналось немного не так.

Причина была другая, но решения проблем будет совпадать.
Нет ничего страшнее чем то что "исторически сложилось".
И в одном моем проекте «исторически сложилась» ситуация, когда картинки отдает php.
В свое время нужно было сделать файловый загрузчик с различными ACL, ресайзами и вотермарками. Это было почти 10 лет назад. Механизм прижился и с тех пор не менялся.
Сейчас для решения таких проблем есть много специализированных решений(elliptics, backpack и другие; а еще лучше CDN). Но тратить человекомесяцы на переход не хочется. Спать хочется, а не работать.
Да и php чтука, в принципе, неплохая. Но имеет свои пределы.
Но проблема тормозных бэкендов решена

Хабр, в очередной раз подсказал вариант решения — proxy_store и proxy_cache.
Но proxy_store использовать мне нельзя — сохранить негде, и с proxy_cache тоже проблемы.
Есть одно, большое такое, «но» — много лет назад я уже столкнулся с производительностью отдачи файлов и решил «пускай лучше nginx отдает конечные файлы за меня».
X-Accel-Redirect.
Проблема — nginx не может закешировать ответ из прокси если это не ответ, а команда. X-Accel-Redirect — не кешируется.
Выхода нет?
Исходную проблему зафиксировали

Теперь вернемся к началу топика.
Нам нужно отдать статику, на этот раз без вмешательства «умных» бэкэндов. Просто статику, но с glusterfs.
Директив для кеширования статики просто нет — не предусмотрены. Считается что OS сама не дура. Для статики есть только open_file_cache и настройка самой передачи файлов(sendfile/aio и компания).
Что делать?
Усложним задачу, и попробуем решить проблему исключительно средствами nginx, не внося никаких изменений в другие коды.
обычный конфиг
# Static files location location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|swf|txt|ico)$ { root /var/www/kashey; }
Пропатченый конфиг

Nginx делает proxy_pass сам на себя, кешируя результат. Возможно тут можно использовать fcgi, но так — нагляднее.
# Static files location location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|swf|txt|ico)$ { set $dopass 1; proxy_set_header Host $host; #если у нас есть "кука" - отдаем файл с реальной ФС if ($http_fiberpass) { root /var/www/kashey; #или proxy_pass на бэкэнд set $dopass 0; break; #но этот break не работает } #настройки кеширования, не забудьте описать proxy_cache_valid proxy_cache static_cache; #добавляем прокси "куку" proxy_set_header fiberpass "nginx"; if ($dopass) { #отправляем запрос к самому себе. proxy_pass http://127.0.0.1:80; } }

И никакой магии.
В случае с X-Accel-Redirect схема такая:
1. nginx получается запрос
2. пересылает себе, к сожалению запрос полный и реальный.
3. пересылает на прокси
4. получает ответ и отдает файл
5. ответ кешируется
6. ???
7. PROFIT

В случае с обычной статикой сложнее — root не заканчивает выполнение, break и return также не работают. Настройка прокси не может находиться внутри условного блока.
Что это дает?

В смысле с X-Accel-Redirect с apache снимается вал запросов. На загруженной системе разница может составить 50 раз.
Но это понятно — php сам по себе, а через апач тем более, не самое реактивное решение.
Latenсy запроса меньше 40мс, лично у меня, не получался (общее время php+gluster).
В случае использования варианта с proxy_cache скорость отдачи приравнивается к скорости отдачи статики.
А что со статикой?

Отдача с gluster — 13мс — это нормальное время для системы без кеша.

Отдача из кеша — 1мс — это замечательное.

Важно учесть — сервера находятся в Германии, а клиенты в России.
Нормальные пинги до сайта 60-100мс.
Так что для клиента ускорение практически не заметно.

Но оно заметно для сервера.
1. Снизилась нагрузка на сервера, в том числе в попугаях Load average и soft-irq.
2. Снизился трафик между серверами (можно решить включив WORM(Write Once Read Many volume), но это уже не «прозрачно»).

3. Все стало работать чуть быстрее.

В итоге работы которые на 10% снизили скорость реакции на клиенте, получились в результате 10-ти кратного ускорения отдачи статики. Что снизило общую нагрузку на сервера примерно раз в 20.
Обратное утверждение, к сожалению, тоже будет верно — сколько не старайся, клиент может и не заметить.

PS: Многие знакомые сисадмины даже не допускали мысли о возможности работы такой схемы. Не позволяет кешировать/проксировать — значит нельзя.

Хорошие программисты не всегда хорошие сисадмины, а сисадмины, обычно, вообще не программисты.
Настоящие герои всегда идут в обход, в брод, и на велосипедах.

PPS: я, кстати, не сисадмин. И, быть может, все сделал не правильно.

Кэширование статических объектов сайта для ускорения загрузки

После всесторонней оптимизации сайта, он поднимается в ранжировании. Таким образом,увеличивается конверсия, а соответственно — доход, который получает бизнес. Чтобы провести правильные настройки, необходимо разработать структуру аудита, которая включает в себя доскональную проверку всех скриптов и конетнта. Команда наших специалистов работает в данном направлении поэтапно, выделяя критические моменты, которые могут полностью менять работоспособность страницы и скорость её загрузки. После проведения полного спектра операций, сервисы проверки WordPress, в том числе и анализатор PageSpeed Insights, даёт 100% результат. А это значит, что сайт проходит аудит без проблем и становится рекомендуемым для пользователей.

При проведении аудита PageSpeed Insights, в качестве рекомендаций, можно увидеть следующую: «Настройка правил эффективного использования кэша для статических объектов». В данном материале мы расскажем что это такое, зачем нужно и с помощью каких инструментов достигается.

Что такое кэш файлов и зачем он нужен

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

Что имеет смысл кэшировать? Все данные, которые обновляются реже чем один раз в несколько минут. К таковым относятся CSS, картинки, javascriptы, таблицы, архивные данные и другие документы, которые требуют загрузки.

Как произвести кэширование статических объектов

Для того, чтобы осуществить кэширование объектов, необходимо использовать заголовок Cache-Control непосредственно в HTTP. Выглядит это приблизительно таким образом:

Cache-Control: private, max-age=31557600

Теперь разберёмся, какую информацию данная запись в себе несёт. В первую очередь, необходимо определить формат кэширования. Они бывают следующими:

●  Private — определяет, что кэширование будет производиться непосредственно на устройстве пользователя;

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

●  No-cache — говорит браузеру о том, что кэшировать данный запрос не следует;

●  Max-age — определяет время в течении которого необходимо сохранять файлы в кэше.

К примеру, если установить max-age равное 31557600, то это значит, что данные будут сохранены в локальном хранилище в течении года. Время указывается в секундах. Если рассматривать Google Chrome, то он обслуживает наиболее запрашиваемые ресурсы из кэша памяти и работает очень быстро, но очищается при закрытии браузера.

Для того, чтобы настроить работу кэша, вполне достаточно использования Cache-Control, но для максимально эффективного использования, вместе с ним нужно применять и другие заголовки.

●  Expires показывает конкретную дату и время, когда кэш будет обновлён. Строка Expires: Thu, 31 Dec 2037 23:55:55 GMT значит, что он обновится за 5 минут до наступления 2038 года по Гринвичу.

●  Vary даёт возможность прописывать дополнительные правила при кэшировании. К примеру, сообщить браузеру, что контент может иметь различия в зависимости от той версии, которую использует пользователь. Одними из наиболее частых являются мобильные или ПК версии

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

Кэширование с использованием плагинов

Упростить процесс кэширования страниц можно используя разработанные плагины. К примеру, W3 Total Cache или WP Super Cache. Чтобы начать ими пользоваться, достаточно просто произвести их установку и они будут кэшировать записи и страницы WordPress в виде статических файлов. А пользователям передавать уже статические файлы, что существенно снижает нагрузку на сервер. Для статичных страниц, даже довольно тяжёлых, это позволяет повысить производительность в несколько сотен раз.

Если применять эти действия в сочетании с кэшем страниц системного уровня, таким как Varnish, то результат получится максимально эффективным. Моэно проводить и кэширование страниц с динамическим контентом, но в этом случае, его настройка гораздо сложнее.

Какие ресурсы являются кэшируемыми

Lighthouse считает, что ресурс является кэшируемым только в том случае, если соблюдены все следующие условия:

●  Этот шрифт, изображение, мультимедийный файл, скрипт или таблица стилей

●  Он имеет код состояния HTTP 200, 203 или 206

●  У него нет явной политики отсутствия кэша.

После этого, Lighthouse оценивает, сколько сетевых данных вы могли бы сохранить своим пользователям, если бы данные ресурсы были кэшированы. Эта оценка включает в себя некоторые расчеты оптимальной длительности кэша для каждого ресурса, на основе совокупной статистики использования Chrome. Не стоит устанавлявать большую продолжительность кэширования для каждого файла. Такое решение далеко не всегда является правильным.

c # - как в ASP.Net включить кеширование в браузере для статического содержимого и отключить его для динамического содержимого?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
.

Настроить кэширование вывода IIS 7

  • 7 минут на чтение

В этой статье

Тали Смит

Internet Information Services (IIS) включает функцию кэша вывода, которая может кэшировать динамическое содержимое PHP (или вывод из Microsoft® ASP.NET, классического ASP или других динамических страниц) в памяти.Это может привести к огромному повышению производительности, поскольку сценарий, используемый для генерации динамического вывода, не нужно запускать для каждого запроса. Кэш может изменять вывод, который кэшируется на основе значений строки запроса, а также заголовков HTTP, отправленных от клиента на сервер. Кэш также интегрирован с драйвером режима ядра Http.sys, что повышает производительность.

Когда использовать кэширование вывода

Веб-контент можно разделить на две основные категории: статический контент и динамический контент.

  • Статическое содержимое не меняется от запроса к запросу. Контент, который возвращается в веб-браузер, всегда один и тот же. Примеры статического содержимого включают файлы HTML, JPG или GIF.
  • Выводится динамическое содержимое, которое изменяется при каждом запросе. Примеры включают содержимое ASP.NET или PHP.

Между этими двумя категориями находится полудинамический контент. Представьте себе динамическую страницу ASP.NET, которая выполняет запрос к базе данных. Нет причин выполнять этот запрос при каждом запросе, если базовые таблицы базы данных меняются нечасто.

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

Функция кэширования вывода IIS предназначена для полудинамического содержимого. Он позволяет кэшировать статические ответы для динамических запросов и повысить масштабируемость.

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

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

Выберите политику кэширования

IIS поддерживает два типа политик кеширования:

  • variableByQuerystring, в котором URL-адрес тот же, но значение строки запроса меняется.
  • varybyHeaders, которые могут изменять кэш в зависимости от заголовков HTTP, отправляемых от клиента на сервер.

Сделать кеш недействительным

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

IIS поддерживает два способа аннулирования динамического содержимого:

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

Настроить пригодность кеша

Даже если вы включите кэширование вывода, IIS не кэширует запрос немедленно.Его необходимо запросить несколько раз, прежде чем IIS сочтет запрос «подходящим для кеширования». Достаточность кеширования можно настроить в разделе ServerRuntime, описанном в статье ServerRuntimeSection Class.

Два свойства определяют пригодность кеша:

  • частыйHitTimePeriod
  • частыйHitThreshold

Запрос кэшируется только в том случае, если более запросов для кэшируемого URL-адреса поступает в пределах .Значение по умолчанию для partialHitTimePeriod - 10 секунд. Значение по умолчанию для partialHitThreshold - 2 хита.

Настроить кэширование вывода с помощью диспетчера IIS

Кэш довольно легко настроить с помощью функции пользовательского интерфейса в новом инструменте администрирования IIS.

  1. В меню Пуск щелкните Администрирование , а затем щелкните Диспетчер информационных служб Интернета (IIS) .

  2. Найдите свое приложение в древовидной структуре слева.

  3. Выберите пункт меню Кэширование вывода .

  4. В правом столбце щелкните Добавить в меню Действие . Здесь вы можете добавить свое правило кэширования вывода.

  5. В поле Расширение имени файла , например, введите .php , а затем выберите Кэширование в пользовательском режиме .

  6. Щелкните Advanced , а затем установите флажок Строковые переменные запроса .

  7. Введите соответствующие переменные в текстовое поле Строковые переменные запроса .

    Рисунок 1. Пример кэширования вывода

Настроить кэширование вывода через файл Web.config

Вы также можете настроить функцию кэширования в локальном файле Web.config, который находится в каталоге содержимого. Ниже приведен пример конфигурации, необходимой для страницы ShowStockPrice.asp с параметром variableByQueryString, равным * (что означает кэширование всех уникальных вариантов параметров строки запроса) и таймаутом в 1 секунду.

  <конфигурация>   <кеширование> <профили>

Если вы хотите кэшировать эти данные в ядре для еще большей производительности, вам просто нужно изменить атрибут политики на kernelCachePolicy.

Примечание

Microsoft ASP.NET уже включает функцию кеширования вывода; Функция кэша вывода IIS работает параллельно с кешем ASP.NET и работает для всех типов приложений.

Проверить счетчики производительности

Чтобы увидеть производительность в кэше вывода, вы можете посмотреть счетчики кэша вывода в мониторе надежности и производительности.

  1. В меню Пуск щелкните Администрирование , а затем щелкните Монитор надежности и производительности .(В Windows Vista® или Windows® 7 средства администрирования находятся на панели управления.)
  2. Выберите Performance Monitor в древовидной структуре справа, а затем щелкните + на панели инструментов.
  3. Перейдите к счетчику кэша веб-служб и щелкните его, чтобы открыть.
  4. Добавьте счетчик Всего кэшированных URI .

Если вы запустите тест производительности, вы увидите, что количество кэшированных URI увеличивается с количеством запрашиваемых вами элементов.

Использовать кэширование в режиме ядра

Кэш вывода IIS поддерживает две политики кеширования:

  • Политика кэша вывода пользовательского режима, которая использует кэш, находящийся в рабочем процессе IIS.
  • Политика кэширования режима ядра, которая использует кэш, расположенный в Http.sys, драйвере режима ядра.

Кэширование содержимого в режиме ядра позволяет повысить производительность веб-сайта. Пример использования кэширования в режиме ядра можно найти в статье IIS Output Caching.

Обратите внимание, что есть два существенных различия между кешем вывода в пользовательском режиме и в режиме ядра.

  • Кэш вывода режима ядра не поддерживает модули и функции, которые должны работать в пользовательском режиме, такие как аутентификация или авторизация. Например, если включены такие схемы проверки подлинности, как базовая проверка подлинности или проверка подлинности Windows®, политика кэширования не работает. Контент обслуживается, но не кэшируется. Вы можете найти более подробную информацию о том, почему ответы могут не кэшироваться в режиме ядра, в этой статье базы знаний.
  • Кэш вывода в режиме ядра поддерживает атрибутariByHeaders, но не поддерживает атрибут variableByQuerystring.

Устранение неполадок кэширования

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

Чтобы узнать, какой контент кэшируется в режиме ядра, можно использовать следующую команду: 

  netsh http показать cachestate

Кэшируйте самые популярные страницы

Вы можете настроить кеш вывода для кеширования только вашей страницы по умолчанию (наиболее часто запрашиваемой страницы):

  1. Создайте файл с именем default.aspx в каталоге % systemdrive% \ inetpub \ wwwroot \ <ваше приложение> и добавьте следующий код: 

      <% = DateTime.Now%>

  2. В меню Пуск щелкните Администрирование , а затем щелкните Диспетчер информационных служб Интернета (IIS) .

  3. Используйте представление в виде дерева слева, чтобы перейти к своему приложению.

  4. Щелкните Content View внизу страницы.

  5. Выберите документ по умолчанию (например, страницу Default.aspx).

  6. В меню Действия справа щелкните Перейти к представлению функции . Каждый настраиваемый параметр теперь применяется только к документу по умолчанию.

  7. Откройте настройку Правила кэширования вывода .

  8. Добавьте .aspx в качестве расширения файла.

  9. Выберите Кэширование в режиме ядра , выберите В интервале времени , включите Мониторинг кэшированных файлов, , а затем введите временной интервал, например 00:00:30 .

  10. Перейдите к http: // localhost // <ваше приложение> с помощью Windows® Internet Explorer®. Постоянно обновляя страницу (нажмите Ctrl + F5 , чтобы убедиться, что вы не используете кеш браузера), вы видите, что время не меняется в течение 30 секунд.

См. Также

.

Как предотвратить кеширование статических файлов во встроенном экземпляре Jetty?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
.

iis - Как настроить кеш статического содержимого для каждой папки и расширения в IIS7?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
  4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
.

включить статические файлы встроенного кеш-памяти, такие как css / js 304

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся приват
.Руководство по кэшированию

- HTTP-сервер Apache, версия 2.4

Этот документ дополняет mod_cache , mod_cache_disk , mod_file_cache и справочная документация htcacheclean. В нем описывается, как использовать функции кэширования HTTP-сервера Apache для ускорения работы в Интернете и обслуживание прокси, избегая при этом распространенных проблем и неправильной конфигурации.

См. Также

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

RFC2616 с тремя состояниями HTTP-кеширование
mod_cache и его модули провайдера mod_cache_disk обеспечить интеллектуальное кэширование с учетом HTTP. Сам контент хранится в кеше, а mod_cache нацелен на соблюдение всех различных HTTP заголовки и параметры, которые контролируют кэшируемость контента как описано в Раздел 13 RFC2616. mod_cache предназначен как для простых, так и для сложных конфигураций кэширования, где вы имеете дело с прокси-контентом, динамическим локальным контентом или необходимо ускорить доступ к локальным файлам на потенциально медленный диск.
Кэширование общих объектов с двумя состояниями ключ / значение
API кэша общих объектов (socache) и его модули провайдера предоставляют общесерверный кеш общих объектов на основе ключей / значений.Эти модули предназначены для кэширования данных низкого уровня, таких как сеансы SSL и учетные данные для аутентификации. Бэкэнды позволяют хранить данные на уровне сервера в разделяемой памяти или на уровне центра обработки данных в кэше, например как memcache или distcache.
Специализированное кэширование файлов
mod_file_cache предлагает возможность предварительной загрузки файлы в память при запуске сервера, и может улучшить доступ раз и сохранить дескрипторы файлов для часто используемых файлов, поскольку нет необходимости переходить на диск при каждом запросе.

Чтобы извлечь максимальную пользу из этого документа, вы должны быть знакомы с основы HTTP и прочли Руководства пользователя по Сопоставление URL-адресов с файловой системой и Согласование содержания.

Протокол HTTP содержит встроенную поддержку встроенного кэширования. механизм описано в разделе 13 RFC2616, а mod_cache Модуль можно использовать для использования этот.

В отличие от простого двухуровневого кэша ключ / значение, в котором содержимое полностью исчезает, когда больше не свежий, HTTP-кеш включает механизм для сохранения устаревшего содержимого и запроса исходного сервера изменилось ли это устаревшее содержимое, и если нет, сделайте его свежим еще раз.

Запись в кэше HTTP находится в одном из трех состояний:

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

Если содержимое слишком старое (старше свежести срок службы ) считается устаревшим .An Кеш HTTP должен связаться с исходным сервером и проверить, содержание еще свежо перед отправкой устаревшего содержания в клиент. Исходный сервер либо ответит заменой контент, если он еще не действителен, или, в идеале, исходный сервер будет ответьте кодом, чтобы сообщить кешу, что контент все еще свежие, без необходимости создавать или отправлять контент снова. Контент снова становится свежим, и цикл продолжается.

Протокол HTTP позволяет кешу обслуживать устаревшие данные при определенных обстоятельствах, например, при попытке освежить данные с исходным сервером вышли из строя с ошибкой 5xx, или когда другой запрос уже находится в процессе обновления данная запись.В этих случаях заголовок Предупреждение добавляется к ответу.

Не существует
Если кеш заполнен, он оставляет за собой возможность удалить контент. из кеша, чтобы освободить место. Контент можно удалить в любой момент, и может быть устаревшим или свежим. Инструмент htcacheclean можно запускаться один раз или развертываться как демон для сохранения размера кеша в пределах заданного размера или заданного количества inodes.Инструмент пытается удалить устаревшее содержимое перед попыткой удалить свежий контент.

Полную информацию о том, как работает HTTP-кеширование, можно найти в Раздел 13 RFC2616.

Взаимодействие с сервером

Модуль mod_cache подключается к серверу двумя возможные места в зависимости от стоимости CacheQuickHandler директива:

Фаза быстрой обработки

Этот этап происходит очень рано во время обработки запроса, сразу после того, как запрос был проанализирован.Если содержание найденный в кеше, он обслуживается немедленно и почти вся обработка запросов не выполняется.

В этом сценарии кеш ведет себя так, как если бы он был заблокирован на "перед сервером.

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

запросов с заголовком «Авторизация» (например, HTTP Basic Аутентификация) не кэшируются и не обслуживаются из кеша когда mod_cache работает на этом этапе.

Обычная фаза обработчика

Эта фаза происходит в конце обработки запроса, в конце концов этапы запроса завершены.

В этом сценарии кеш ведет себя так, как если бы он был заблокирован на "к задней части сервера.

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

Если URL-адрес не найден в кэше, mod_cache добавит фильтр в стек фильтров, чтобы записать ответ в кеш, а затем остановиться, разрешив нормальный обработка запроса продолжается.Если содержание определено как кэшируемый, контент будет сохранен в кеш для дальнейшего обслуживания, в противном случае содержимое будет проигнорировано.

Если содержимое, обнаруженное в кэше, устарело, mod_cache Модуль преобразует запрос в условный запрос . Если исходный сервер отвечает нормальный ответ, нормальный ответ кэшируется, заменяя содержимое уже кешировано. Если исходный сервер отвечает 304 Not Modified ответ, контент снова помечается как свежий, а кешированный контент обслуживается фильтром, а не сохраняется.

Улучшение обращений к кеш-памяти

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

Срок службы свежести

Правильно сформированный контент, предназначенный для кэширования, должен объявлять явное время жизни свежести с Cache-Control поля заголовка max-age или s-maxage , или включив заголовок Expires .

В то же время, время жизни, определенное исходным сервером, может быть отменено клиентом, когда клиент представляет свои собственные Cache-Control заголовок в запросе.В этом случае, побеждает наименьшее время жизни между запросом и ответом.

Когда это время жизни отсутствует в запросе или ответа, применяется время действия по умолчанию. По умолчанию время жизни для кешированных объектов составляет один час, однако это можно легко изменить с помощью директивы CacheDefaultExpire .

Если ответ не включает заголовок Expires , но содержит включить заголовок Last-Modified , mod_cache может сделать вывод о продолжительности жизни на основе эвристики, которая может быть контролируется с помощью директивы CacheLastModifiedFactor .

Для локального контента или для удаленного контента, который не определяет свой собственный Expires header, mod_expires можно использовать для точно настроить срок свежести, добавив max-age и Истекает .

Максимальный срок свежести можно также контролировать с помощью CacheMaxExpire .

Краткое руководство по условным запросам

Когда содержимое из кэша истекает и становится устаревшим, а не передать исходный запрос, httpd изменит запрос, чтобы сделать это условно вместо этого.

Когда заголовок ETag существует в исходной кэшированной ответ, mod_cache добавит If-None-Соответствует заголовку запросу к исходному серверу. Когда заголовок Last-Modified существует в исходном кешированный ответ, mod_cache добавит If-Modified-Since заголовок запроса к источнику сервер. При выполнении любого из этих действий запрос условно .

Когда условный запрос получен исходным сервером, origin-сервер должен проверить, является ли ETag или Last-Modified параметр был изменен в соответствии с запросом. Если нет, то origin должен ответить кратким ответом «304 Not Modified». Этот сигналы кешу о том, что устаревшее содержимое еще свежо, должны быть используется для последующих запросов до нового времени жизни контента снова достигается.

Если содержимое изменилось, оно обслуживается так, как если бы Запрос изначально не был условным.

Условные запросы дают два преимущества. Во-первых, при изготовлении таких запрос к исходному серверу, если контент из источника совпадает с содержимым в кеше, это можно легко определить и без накладных расходов на перенос всего ресурса.

Во-вторых, хорошо спроектированный исходный сервер будет спроектирован в таком способ, которым условные запросы будут значительно дешевле производим чем полный ответ. Для статических файлов обычно все задействован вызов stat () или аналогичный системный вызов, чтобы посмотрите, изменился ли файл по размеру или времени модификации.Таким образом, даже локальный контент может по-прежнему обслуживаться из кеша быстрее, если он не изменилось.

Серверы

Origin должны приложить все усилия для поддержки условных запросы, как это практически возможно, однако если условные запросы не поддерживается, источник ответит, как если бы запрос не был условно, и кеш будет реагировать, как если бы содержимое было изменено и сохраните новый контент в кеш. В этом случае кеш будет вести себя как простой кеш с двумя состояниями, где контент эффективно либо свежие, либо удаленные.

Что можно кэшировать?

Полное определение того, какие ответы могут кэшироваться по протоколу HTTP. кеш определяется в RFC2616, раздел 13.4 Кэшируемость ответа, и его можно резюмировать как следует:

  1. Кэширование должно быть включено для этого URL. См. Директивы CacheEnable и CacheDisable .
  2. Если ответ имеет код состояния HTTP, отличный от 200, 203, 300, 301 или 410, он также должен указывать заголовок «Expires» или «Cache-Control».
  3. Запрос должен быть запросом HTTP GET.
  4. Если ответ содержит заголовок «Авторизация:», он должен также содержат параметр "s-maxage", "must-revalidate" или "public" в заголовке «Cache-Control:», иначе он не будет кэшироваться.
  5. Если URL-адрес включает строку запроса (например, из HTML-формы GET метод) он не будет кэшироваться, если в ответе не указан явное истечение срока действия путем включения заголовка "Expires:" или максимального возраста или директива s-maxage заголовка «Cache-Control:» согласно RFC2616 Разделы 13.9 и 13.2.1.
  6. Если ответ имеет статус 200 (ОК), ответ должен также включать по крайней мере один из Etag, Last-Modified или заголовки Expires или директивы max-age или s-maxage для заголовок "Cache-Control:", если только CacheIgnoreNoLastMod директива использовалась, чтобы требовать иначе.
  7. Если ответ включает параметр «private» в «Cache-Control:» заголовок, он не будет сохранен, если CacheStorePrivate был раньше требовали иначе.
  8. Аналогичным образом, если ответ включает в себя опцию «no-store» в Заголовок "Cache-Control:" не будет сохранен, если CacheStoreNoStore был используемый.
  9. Ответ не будет сохранен, если он включает заголовок "Vary:" содержащий совпадение "*".

Что не следует кэшировать?

Это должно быть на усмотрение клиента, создающего запрос, или источника сервер строит ответ, чтобы решить, действительно ли контент должен быть кэшируемым или нет, правильно установив Заголовок Cache-Control и mod_cache должен быть оставленным в покое, чтобы выполнить пожелания клиента или сервера в зависимости от ситуации.

Контент, чувствительный ко времени или изменяющийся в зависимости от сведения о запросе, не охваченные согласованием HTTP, не следует кэшировать. Этот контент должен объявить себя некэшируемым используя заголовок Cache-Control .

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

Контент, который варьируется в зависимости от предоставленных клиентом заголовков запросов, может быть кэшируется за счет интеллектуального использования ответа Vary заголовок.

Переменное / согласованное содержимое

Когда исходный сервер предназначен для ответа с другим контентом на основе значения заголовков в запросе, например для обслуживания несколько языков по одному и тому же URL-адресу, механизм кеширования HTTP делает это можно кэшировать несколько вариантов одной и той же страницы по одному и тому же URL.

Это выполняется исходным сервером, добавляющим заголовок Vary чтобы указать, какие заголовки должны учитываться кешем, когда определение того, отличаются ли два варианта друг от друга.

Если, например, получен ответ с изменяемым заголовком, например;

Варьировать: переговоры, accept-language, accept-charset

mod_cache будет обслуживать кэшированный контент только запрашивающие с заголовками accept-language и accept-charset совпадающие с исходным запросом.

Несколько вариантов содержимого можно кэшировать бок о бок, mod_cache использует заголовок Vary и соответствующие значения заголовков запросов, перечисленных в Vary решить, какой из множества вариантов вернуть клиенту.

Кэширование на диск

Модуль mod_cache полагается на определенное внутреннее хранилище реализации для управления кешем и для кэширования на диск mod_cache_disk предназначен для поддержки этого.

Обычно модуль настроен таким образом; 

 CacheRoot "/ var / cache / apache /" CacheEnable disk / CacheDirLevels 2 CacheDirLength 1

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

Понимание кэш-хранилища

Для хранения элементов в кеше mod_cache_disk создает 22-символьный хэш запрашиваемого URL. Этот хеш включает имя хоста, протокол, порт, путь и любые аргументы CGI для URL-адреса, а также элементы, определенные заголовком Vary, чтобы гарантировать, что несколько URL-адреса не конфликтуют друг с другом.

Каждый символ может быть любым из 64-х различных символов, что означает что всего существует 64 ^ 22 возможных хэша.Например, URL-адрес может хешируется до xyTGxSMO2b68mBCykqkp1w . Этот хеш используется в качестве префикса для именования файлов, относящихся к этому URL-адресу в кеш, однако сначала он разбивается на каталоги в соответствии с CacheDirLevels и CacheDirLength директивы.

CacheDirLevels указывает, сколько уровней подкаталога должно быть, и CacheDirLength указывает, сколько символов должно быть в каждом каталоге.С участием в приведенном выше примере настроек хеш будет преобразован в префикс имени файла как / var / cache / apache / x / y / TGxSMO2b68mBCykqkp1w .

Общая цель этого метода - уменьшить количество подкаталоги или файлы, которые могут находиться в определенном каталоге, поскольку большинство файловых систем замедляются по мере увеличения этого числа. С участием установка "1" для CacheDirLength на любом уровне может быть не более 64 подкаталогов.При настройке 2 может быть 64 * 64 подкаталога и так далее. Если у вас нет веской причины не делать этого, используйте настройку "1" для CacheDirLength Рекомендовано.

Настройка CacheDirLevels зависит от того, сколько файлов вы планируете хранить в кеше. С настройкой "2", использованной в приведенном выше примере, большая Всего можно создать 4096 подкаталогов. С участием Кэшируется 1 миллион файлов, это примерно 245 кэшированных файлов. URL-адреса на каталог.

Каждый URL использует как минимум два файла в хранилище кешей. Обычно есть файл ".header", который включает метаинформацию о URL-адрес, например, когда истекает срок его действия, и файл ".data" который представляет собой дословную копию контента, который будет обслуживаться.

В случае согласования содержимого через заголовок "Vary", Каталог ".vary" будет создан для рассматриваемого URL. Этот в каталоге будет несколько файлов ".data", соответствующих иначе согласованный контент.

Обслуживание дискового кэша

Модуль mod_cache_disk не пытается регулировать объем дискового пространства, используемого кешем, хотя он изящно устранит любую ошибку диска и будет вести себя так, как если бы кеша никогда не было.

Вместо httpd предоставляется инструмент htcacheclean, который позволяет периодически чистить кеш. Определение того, как часто запускать htcacheclean и какой целевой размер использование кеша довольно сложно, и может потребоваться метод проб и ошибок, чтобы выбрать оптимальные значения.

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

Также рекомендуется выбрать соответствующий "хороший" уровень для htcacheclean, чтобы инструмент не приводил к чрезмерному увеличению нагрузки на диск, пока сервер работает.


Рисунок 1 : Типичный последовательность роста / очистки кеша.

Потому что mod_cache_disk сам не обращает внимания сколько места используется, вы должны убедиться, что htcacheclean настроен на оставьте достаточно места для выращивания после уборки.

Кэширование в memcached

Использование модуля mod_cache_socache , mod_cache может кэшировать данные из различных реализаций (также известных как «поставщики»).С использованием mod_socache_memcache Модуль , например, можно указать, что memcached должен использоваться как механизм внутреннего хранилища.

Обычно модуль имеет такую ​​конфигурацию: 

 CacheEnable socache / CacheSocache memcache: memcd.example.com: 11211

Дополнительные сервера memcached могут быть указаны добавляя их в конец кэша памяти CacheSocache: строка через запятую: 

 CacheEnable socache / CacheSocache кэш памяти: mem1.example.com:11211,mem2.example.com:11212

Этот формат также используется с другими mod_cache_socache провайдеры. Например: 

 CacheEnable socache / CacheSocache shmcb: / путь / к / файлу данных (512000) 
 CacheEnable socache / БД CacheSocache: / путь / к / файлу данных

На платформах, где файловая система может работать медленно или ручки дороги, существует возможность предварительной загрузки файлов в память при запуске.

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

Кэширование дескрипторов файлов

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

файл кэша

Самая простая форма кэширования в httpd - дескриптор файла. кеширование обеспечивается mod_file_cache . Вместо кеширования file-contents, этот кеш поддерживает таблицу дескрипторов открытых файлов. Файлы для кэширования таким образом указываются в файле конфигурации с помощью файл кэша директива.

CacheFile директива указывает httpd открыть файл при его запуске и повторно использовать этот дескриптор файла для всего последующего доступа к этому файлу.

 CacheFile /usr/local/apache2/htdocs/index.html

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

Хотя используется CacheFile не приводит к кэшированию содержимого файла как такового, это означает что если файл изменяется во время работы httpd, эти изменения будут не быть поднятым.Файл будет постоянно обслуживаться в том виде, в котором он был при запуске httpd.

Если файл будет удален во время работы httpd, он продолжится чтобы поддерживать дескриптор открытого файла и обслуживать файл, как когда httpd был запущен. Обычно это также означает, что хотя файл будут удалены и не будут отображаться в файловой системе, дополнительно бесплатно пространство не будет восстановлено, пока httpd не будет остановлен и файл дескриптор закрыт.

Кэширование в памяти

Обслуживание непосредственно из системной памяти - универсальный самый быстрый метод обслуживания контента.Чтение файлов с контроллера диска или, что еще хуже, из удаленной сети на порядки медленнее. Контроллеры дисков обычно связаны с физическими процессами, а доступ к сети ограничен доступная пропускная способность. С другой стороны, доступ к памяти может занять наносекунды.

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

Кэширование операционной системы

Практически все современные операционные системы кэшируют файлы-данные в управляемой памяти. непосредственно ядром.Это мощная функция, и для большинства часть операционных систем понимает это правильно. Например, в Linux давайте посмотрим на разница во времени, необходимом для чтения файла в первый раз и второй раз; 

 colm @ coroebus: ~ тестовый файл $ time cat> / dev / null реальный 0m0.065s пользователь 0m0.000s sys 0m0.001s colm @ coroebus: ~ тестовый файл $ time cat> / dev / null реальный 0m0.003s пользователь 0m0.003s sys 0m0.000s

Даже для этого небольшого файла огромная разница в количестве времени, необходимого для чтения файла.Это потому, что ядро ​​кэшировало содержимое файла в памяти.

Убедившись, что в вашей системе есть "свободная" память, вы можете что все больше и больше файлового содержимого будет храниться в этом кеше. Этот может быть очень эффективным средством кэширования в памяти и не требует лишняя настройка httpd вообще.

Кроме того, поскольку операционная система знает, когда файлы удален или изменен, он может автоматически удалять содержимое файла из кешируйте при необходимости.Это большое преимущество перед httpd в памяти. кэширование, которое не знает, когда файл был изменен.

Несмотря на производительность и преимущества автоматической операционной системы кэширование есть некоторые обстоятельства, при которых кэширование в памяти может быть лучше выполняется httpd.

Кэширование MMapFile

mod_file_cache предоставляет MMapFile директива, которая позволяет httpd отображать содержимое статического файла в память по адресу время начала (с помощью системного вызова mmap).httpd будет использовать в памяти содержимое для всех последующих обращений к этому файлу. 

 MMapFile /usr/local/apache2/htdocs/index.html

Как и CacheFile директива, любая изменения в этих файлах не будут приняты httpd после того, как он началось.

MMapFile директива не отслеживает, сколько памяти она выделяет, поэтому вы должны убедиться, что не злоупотребляете директивой.Каждый ребенок httpd процесс будет копировать эту память, поэтому это критически важно чтобы гарантировать, что отображаемые файлы не настолько велики, чтобы вызвать система подкачки памяти.

Авторизация и контроль доступа

Использование mod_cache в состоянии по умолчанию, где CacheQuickHandler установлен на На очень похоже на подключенный кеширующий обратный прокси к передней части сервера.Запросы будут обслуживаться модулем кеширования если он не определяет, что исходный сервер следует запрашивать так же, как внешний кеш будет, и это радикально изменит модель безопасности httpd.

По мере обхода иерархии файловой системы для проверки потенциальных .htaccess файлов - очень дорогая операция, частичное поражение точки кеширования (для ускорения запросов), mod_cache не принимает решения о том, кэшируется ли субъект авторизован для обслуживания.Другими словами; если mod_cache кэшировал некоторый контент, он будет обслуживаться из кеша, пока срок хранения этого содержимого не истек.

Если, например, ваша конфигурация разрешает доступ к ресурсу по IP адрес, вы должны убедиться, что это содержимое не кэшируется. Ты можешь это сделать с помощью CacheDisable директива или mod_expires . Не отмечено флажком, mod_cache - очень похоже на обратный прокси - будет кешировать контент, когда он обслуживается, а затем обслуживает его любому клиенту на любом IP адрес.

Когда используется CacheQuickHandler директива установлена ​​на Off , полный набор обработки запросов фазы выполняются, а модель безопасности остается неизменной.

Локальные эксплойты

Поскольку запросы к конечным пользователям могут обслуживаться из кеша, кеш сам по себе может стать целью для тех, кто хочет испортить или помешать содержание. Важно помнить, что кеш должен вообще раз будет доступен для записи пользователем, от имени которого запущен httpd.Это в разительный контраст с обычно рекомендуемой ситуацией поддержания все содержимое недоступно для записи пользователем Apache.

Если пользователь Apache скомпрометирован, например, из-за уязвимости в процесс CGI, возможно, что кэш может быть целевым. когда используя mod_cache_disk , относительно легко вставить или изменить кэшированный объект.

Это представляет несколько повышенный риск по сравнению с другими типы атак можно совершить как пользователь Apache.Если ты используя mod_cache_disk , вы должны иметь это в виду - убедитесь, что вы обновили httpd, когда будут объявлены обновления безопасности и запускать процессы CGI от имени пользователя, отличного от Apache, если возможно, с помощью suEXEC.

Отравление кэша

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

Например, если DNS-серверы, используемые вашей системой, запускают httpd уязвимы для отравления кеша DNS, злоумышленник может контролировать где httpd подключается при запросе контента с исходного сервера. Другой пример - так называемые атаки с использованием HTTP-запросов.

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

Отказ в обслуживании / очистка кеша

Механизм Vary позволяет использовать несколько вариантов одного и того же URL-адреса. кешируются бок о бок. В зависимости от значений заголовка, предоставленных клиентом, кеш выберет правильный вариант для возврата клиенту. Этот механизм может стать проблемой, если попытаться изменить заголовок, который, как известно, содержит широкий диапазон возможных значений в нормальное использование, например заголовок User-Agent .В зависимости от от популярности конкретного веб-сайта тысячи или миллионы повторяющиеся записи в кеше могут быть созданы для одного и того же URL, переполнение из других записей в кеше.

В других случаях может потребоваться изменить URL-адрес определенного ресурс по каждому запросу, обычно путем добавления строки "cachebuster" в URL-адрес. Если этот контент объявлен кешируемым сервером для значительный срок свежести, эти записи могут вытеснить легитимные записи в кеше.Пока mod_cache обеспечивает CacheIgnoreURLSessionIdentifiers директиву, эту директиву следует использовать с осторожностью, чтобы гарантировать, что нижестоящие прокси или кеши браузера не подвергаются тому же отказу вопроса обслуживания.

.

Смотрите также