Кэширование с Nginx. Подводные камни при использовании кэширования в nginx Кэширование centos 6 gzip nginx

We all know that the performance of applications and web sites is a critical factor in their success. The process of making your application or web site perform better, however, is not always clear. Code quality and infrastructure are of course critical, but in many cases you can make vast improvements to the end user experience of your application by focusing on some very basic application delivery techniques. One such example is by implementing and optimizing caching in your application stack. This blog post covers techniques that can help both novice and advanced users see better performance from utilizing the included in NGINX and NGINX Plus.

Overview

A content cache sits in between a client and an “origin server”, and saves copies of all the content it sees. If a client requests content that the cache has stored, it returns the content directly without contacting the origin server. This improves performance as the content cache is closer to the client, and more efficiently uses the application servers because they don’t have to do the work of generating pages from scratch each time.

There are potentially multiple caches between the web browser and the application server: the client’s browser cache, intermediary caches, content delivery networks (CDNs), and the load balancer or reverse proxy sitting in front of the application servers. Caching, even at the reverse proxy/load balancer level, can greatly improve performance.

As an example, last year I took on the task of performance tuning a website that was loading slowly. One of the first things I noticed was that it took over 1 second to generate the main home page. After some debugging, I discovered that because the page was marked as not cacheable, it was being dynamically generated in response to each request. The page itself was not changing very often and was not personalized, so this was not necessary. As an experiment, I marked the homepage to be cached for 5 seconds by the load balancer, and just doing that resulted in noticeable improvement. The time to first byte went down to a few milliseconds and the page loaded visibly faster.

NGINX is commonly deployed as a reverse proxy or load balancer in an application stack and has a full set of caching features. The next section discusses how to configure basic caching with NGINX.

How to Set Up and Configure Basic Caching

Only two directives are needed to enable basic caching: proxy_cache_path and proxy_cache . The proxy_cache_path directive sets the path and configuration of the cache, and the proxy_cache directive activates it.

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { # ... location / { proxy_cache my_cache; proxy_pass http://my_upstream; } }

The parameters to the proxy_cache_path directive define the following settings:

The local disk directory for the cache is called /path/to/cache/ .
levels sets up a two‑level directory hierarchy under /path/to/cache/ . Having a large number of files in a single directory can slow down file access, so we recommend a two‑level directory hierarchy for most deployments. If the levels parameter is not included, NGINX puts all files in the same directory.
keys_zone sets up a shared memory zone for storing the cache keys and metadata such as usage timers. Having a copy of the keys in memory enables NGINX to quickly determine if a request is a HIT or a MISS without having to go to disk, greatly speeding up the check. A 1‑MB zone can store data for about 8,000 keys, so the 10‑MB zone configured in the example can store data for about 80,000 keys.
max_size sets the upper limit of the size of the cache (to 10 gigabytes in this example). It is optional; not specifying a value allows the cache to grow to use all available disk space. When the cache size reaches the limit, a process called the cache manager removes the files that were least recently used to bring the cache size back under the limit.
inactive specifies how long an item can remain in the cache without being accessed. In this example, a file that has not been requested for 60 minutes is automatically deleted from the cache by the cache manager process, regardless of whether or not it has expired. The default value is 10 minutes (10m). Inactive content differs from expired content. NGINX does not automatically delete content that has expired as defined by a cache control header (Cache-Control:max-age=120 for example). Expired (stale) content is deleted only when it has not been accessed for the time specified by inactive . When expired content is accessed, NGINX refreshes it from the origin server and resets the inactive timer.
NGINX first writes files that are destined for the cache to a temporary storage area, and the use_temp_path=off directive instructs NGINX to write them to the same directories where they will be cached. We recommend that you set this parameter to off to avoid unnecessary copying of data between file systems. use_temp_path was introduced in NGINX version 1.7.10 and .

And finally, the proxy_cache directive activates caching of all content that matches the URL of the parent location block (in the example, / ). You can also include the proxy_cache directive in a server block; it applies to all location blocks for the server that don’t have their own proxy_cache directive.

Delivering Cached Content When the Origin is Down

location / { # ... proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; }

With this sample configuration, if NGINX receives an error , timeout , or any of the specified 5xx errors from the origin server and it has a stale version of the requested file in its cache, it delivers the stale file instead of relaying the error to the client.

Fine‑Tuning the Cache and Improving Performance

NGINX has a wealth of optional settings for fine‑tuning the performance of the cache. Here is an example that activates a few of them:

Proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { # ... location / { proxy_cache my_cache; proxy_cache_revalidate on; proxy_cache_min_uses 3; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; proxy_cache_background_update on; proxy_cache_lock on; proxy_pass http://my_upstream; } }

These directives configure the following behavior:

proxy_cache_revalidate instructs NGINX to use conditional GET requests when refreshing content from the origin servers. If a client requests an item that is cached but expired as defined by the cache control headers, NGINX includes the If-Modified-Since field in the header of the GET request it sends to the origin server. This saves on bandwidth, because the server sends the full item only if it has been modified since the time recorded in the Last-Modified header attached to the file when NGINX originally cached it.
proxy_cache_min_uses sets the number of times an item must be requested by clients before NGINX caches it. This is useful if the cache is constantly filling up, as it ensures that only the most frequently accessed items are added to the cache. By default proxy_cache_min_uses is set to 1.
The updating parameter to the proxy_cache_use_stale directive, combined with enabling the proxy_cache_background_update directive, instructs NGINX to deliver stale content when clients request an item that is expired or is in the process of being updated from the origin server. All updates will be done in the background. The stale file is returned for all requests until the updated file is fully downloaded.
With proxy_cache_lock enabled, if multiple clients request a file that is not current in the cache (a MISS), only the first of those requests is allowed through to the origin server. The remaining requests wait for that request to be satisfied and then pull the file from the cache. Without proxy_cache_lock enabled, all requests that result in cache misses go straight to the origin server.

Splitting the Cache Across Multiple Hard Drives

If you have multiple hard drives, NGINX can be used to split the cache across them. Here is an example that splits clients evenly across two hard drives based on the request URI:

Proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m max_size=10g inactive=60m use_temp_path=off; proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m max_size=10g inactive=60m use_temp_path=off; split_clients $request_uri $my_cache { 50% “my_cache_hdd1”; 50% “my_cache_hdd2”; } server { # ... location / { proxy_cache $my_cache; proxy_pass http://my_upstream; } }

The two proxy_cache_path directives define two caches (my_cache_hdd1 and my_cache_hdd2) on two different hard drives. The split_clients configuration block specifies that the results from half the requests (50%) are cached in my_cache_hdd1 and the other half in my_cache_hdd2 . The hash based on the $request_uri variable (the request URI) determines which cache is used for each request, the result being that requests for a given URI are always cached in the same cache.

Please note this approach is not a replacement for a RAID hard drive setup. If there is a hard drive failure this could lead to unpredictable behavior on the system, including users seeing 500 response codes for requests that were directed to the failed hard drive. A proper RAID hard drive setup can handle hard drive failures.

Frequently Asked Questions (FAQ)

This section answers some frequently asked questions about NGINX content caching.

Can the NGINX Cache Be Instrumented?

add_header X-Cache-Status $upstream_cache_status;

This example adds an X-Cache-Status HTTP header in responses to clients. The following are the possible values for $upstream_cache_status :

How Does NGINX Determine Whether or Not to Cache Something?

By default, NGINX respects the Cache-Control headers from origin servers. It does not cache responses with Cache-Control set to Private , No-Cache , or No-Store or with Set-Cookie in the response header. NGINX only caches GET and HEAD client requests. You can override these defaults as described in the answers below.

proxy_cache_methods GET HEAD POST;

This example enables caching of POST requests.

Can NGINX Cache Dynamic Content?

Yes, provided the Cache-Control header allows for it. Caching dynamic content for even a short period of time can reduce load on origin servers and databases, which improves time to first byte, as the page does not have to be regenerated for each request.

Can I Punch a Hole Through My Cache?

location / { proxy_cache_bypass $cookie_nocache $arg_nocache; # ... }

The directive defines request types for which NGINX requests content from the origin server immediately instead of trying to find it in the cache first. This is sometimes referred to as “punching a hole” through the cache. In this example, NGINX does it for requests with a nocache cookie or argument, for example http://www.example.com/?nocache=true . NGINX can still cache the resulting response for future requests that aren’t bypassed.

What Cache Key Does NGINX Use?

The default form of the keys that NGINX generates is similar to an MD5 hash of the following NGINX variables : $scheme$proxy_host$request_uri ; the actual algorithm used is slightly more complicated.

Proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { # ... location / { proxy_cache my_cache; proxy_pass http://my_upstream; } }

For this sample configuration, the cache key for http://www.example.org/my_image.jpg is calculated as md5(“http://my_upstream:80/my_image.jpg”) .

To change the variables (or other terms) used as the basis for the key, use the proxy_cache_key directive (see also the following question).

Can I Use a Cookie as Part of My Cache Key?

Yes, the cache key can be configured to be any arbitrary value, for example:

proxy_cache_key $proxy_host$request_uri$cookie_jessionid;

This example incorporates the value of the JSESSIONID cookie into the cache key. Items with the same URI but different JSESSIONID values are cached separately as unique items.

Does NGINX Use the ETag Header?

How Does NGINX Handle the Pragma Header?

The Pragma:no-cache header is added by clients to bypass all intermediary caches and go straight to the origin server for the requested content. NGINX does not honor the Pragma header by default, but you can configure the feature with the following proxy_cache_bypass directive:

Location /images/ { proxy_cache my_cache; proxy_cache_bypass $http_pragma; # ... }

Does NGINX Support the stale-while-revalidate and stale-if-error Extensions to the Cache-Control Header?

Does NGINX Support the Vary Header?

Настраиваем GZIP-сжатие на сайте в Nginx

После того как файл конфигурации открыт, в нем нас будут интересовать две секции: это http {…} и server {…}.

Для включения GZIP-сжатия на вашем сайте в секцию http, сразу после «http { », вставьте:

Gzip_static on; gzip on; gzip_buffers 16 8k; gzip_comp_level 9; 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;

Если какие-то из строк уже есть в этой секции, то удалите их. Таким способом мы включили GZIP-сжатие на сайте. Вы также можете поиграть с настройками параметра «gzip_comp_level 9 ». Здесь «9 » – это максимальный уровень сжатия, а минимально возможный – «1 ».

Максимальный уровень требует немного больше ресурсов. Если после включения сжатия вы наблюдаете небольшие зависания сайта, то измените «9 » на «5 » - оптимальное значение.

Настраиваем кэширование файлов на сайте в Nginx

Для настройки кэширования файлов мы будем вносить изменения в секции server.

Для этого сразу после «server { » вставьте:

Location ~* ^.+.(jpg|jpeg|gif|png|ico|css|pdf|ppt|txt|bmp|rtf|js|woff|ttf|svg|swf|mp3|ogg|avi|zip|rar)$ { try_files $uri $uri/ @fallback; expires 7d; }

Здесь «expires 7d; » – это количество дней, которым нужно кэшировать файлы (в нашем случае – 7 дней). Список необходимых файлов вы можете отредактировать сами, а также дополнить его необходимыми форматами.

После того как все необходимые настройки сделаны, вам необходимо перезапустить Nginx.

Для этого в SSH Terminal"e выполните команду:

Service nginx restart

На этом мы заканчиваем настройку, направленную на ускорение работы вашего сайта.

HTTP заголовок Expires наряду с несколькими другими заголовками, такими как Cache-Control позволяет управлять кэшем, тем самым сообщая, как долго запрашиваемый контент будет актуален. После того как «время жизни» истекает, кэш перестает быть актуальным, и возникает необходимость запрашивать исходный ресурс, чтобы узнать были ли изменения в контенте. Заголовок Expires является стандартным заголовком, регламентированным в протоколе HTTP, и поддерживается практически любым кэшом. Что касается заголовка Cache-Control, то он был введен в HTTP/1.1 , позволив тем самым предоставить возможность веб-мастерам осуществлять больший контроль над контентом, а так же решить ограничения связанные с Expires. Чтобы использовать Cache-control эффективно, рекомендуется указывать время, по истечении которого кэш перестает быть актуальным.

В данном посту мы рассмотрим примеры настройки параметра expires в Nginx. Для начала попробуем в настройках выставить максимальный возможный срок хранения кэша.
Ставим кэш на максимальный срок

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires max; } ... }

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

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires 7d; } ... }

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

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires modified 3d; } ... }

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

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires off; } ... }

Заданное таким образом значение полностью отключает действие Сache-control. Используя кэширование, клиентская часть избегает необходимости скачивать контент целиком, т.к. он уже имеет локальные копии файлов. Выставлять время кэширования нужно осмысленно, без лишнего фанатизма, очень долгий кэш может быть не всегда рационален, если данные у вас меняются довольно динамично.

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

Приведу пример для включения этого функционала.

Сразу сделаем оговорку. Вы должны иметь доступ к файл nginx.conf из каталога /usr/local/nginx/conf , или /etc/nginx , или /usr/local/etc/nginx , в зависимости от ОС. Это подразумевает что у Вас выделенный или виртуальный сервер. На обычных хостингах может помочь только обращение в техническую поддержку.

Сжатие GZIP для сайта на NGINX

Выглядит это следующим образом

Http { #buffer_size, разные include и прочие общие настройки gzip on; gzip_min_length 1000; gzip_proxied any; gzip_disable "MSIE \.(?!.*SV1)"; gzip_types text/plain text/xml application/xml application/x-javascript text/javascript text/css text/json; gzip_comp_level 1; server { #настройки каждого из сайтов на сервере } }

Таким образом для всех сайтов на сервере включается сжатие.

Кеширование браузером

Для кеширования необходимы следующие изменения:

Location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { expires 30d; #Остальные директивы }

Таким образом решается эта простая проблема, которая становится порой серьезной головной болью вебмастеров, плохо знакомых с работой системного администратора Linux.

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

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

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

Требования

Сервер Ubuntu 16.04 (о настройке сервера можно узнать ).
Пользователь с доступом к команде sudo.
Предварительно установленный веб-сервер Nginx (руководство по установке – ).
Модуль map (инструкции по настройке этого модуля – в ).

1: Создание тестовых файлов

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

Чтобы определить тип файла, передаваемого по сети, Nginx не анализирует его контент (это было бы слишком медленно), вместо этого он смотрит на расширение файла, чтобы определить его MIME тип, который определяет цель файла.

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

В каталоге Nginx по умолчанию создайте файл test.html с помощью truncate. Как видно по расширению, это будет HTML-файл.

sudo truncate -s 1k /var/www/html/test.html

Таким же образом создайте ещё несколько тестовых файлов с расширениями jpg (изображение), css (таблица стилей) и js (JavaScript):

sudo truncate -s 1k /var/www/html/test.jpg
sudo truncate -s 1k /var/www/html/test.css
sudo truncate -s 1k /var/www/html/test.js

2: Проверка стандартного поведения Nginx

По умолчанию все файлы кэшируются одинаково. Чтобы убедиться в этом, используйте тестовый HTML-файл.

Отправьте запрос к test.html с локального сервера Nginx и просмотрите заголовки ответа:

Эта команда вернёт такой заголовок ответа:

HTTP/1.1 200 OK

Date: Sat, 10 Sep 2016 13:12:26 GMT
Content-Type: text/html
Content-Length: 1024

Connection: keep-alive
ETag: "57d40685-400"
Accept-Ranges: bytes

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

Браузер хранит значение ETag и отправляет его обратно на сервер в заголовке ответа If-None-Match при необходимости повторно запросить файл (например, при обновлении страницы).

Вы можете симулировать это поведение с помощью следующей команды:

curl -I -H "If-None-Match: "57d40685-400"" http://localhost/test.html

Примечание : Укажите своё значение ETag вместо 57f6257c-400.

Теперь команда вернёт:

HTTP/1.1 304 Not Modified
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:20:31 GMT
Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT
Connection: keep-alive
ETag: "57d40685-400"

В этот раз Nginx вернет 304 Not Modified. Веб-сервер не будет пересылать файл снова, он просто сообщит браузеру о том, что он может повторно использовать загруженный ранее файл.

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

3: Настройка заголовков Cache-Control и Expires

Кроме ETag существует ещё два заголовка ответа для управления кэшированием: Cache-Control и Expires. Cache-Control – более новый заголовок, он имеет больше функций, чем Expires, и в целом более полезен в настройке кэширования.

Эти заголовки сообщают браузеру, что запрашиваемый файл можно хранить локально в течение определённого периода (в том числе и всегда) и при этом не запрашивать его снова. Если эти заголовки не настроены, браузер будет вынужден постоянно запрашивать файлы у сервера и ожидать ответа 200 OK или 304 Not Modified.

Эти HTTP-заголовки можно настроить с помощью модуля header. Модуль Header встроен в Nginx, а значит, его не нужно устанавливать.

Чтобы добавить этот модуль, откройте файл виртуального хоста Nginx по умолчанию в текстовом редакторе:

sudo nano /etc/nginx/sites-available/default

Найдите блок server:

. . .

#
server {
listen 80 default_server;

. . .

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

. . .
# Default server configuration
#
# Expires map
map $sent_http_content_type $expires {
default off;
text/html epoch;
text/css max;
application/javascript max;
~image/ max;
}
server {
listen 80 default_server;
listen [::]:80 default_server;
expires $expires;
. . .

Раздел перед блоком server – это новый блок map, который определяет соответствия между типом файла и периодом хранения его в кэше.

off — значение по умолчанию, которое не добавляет заголовков для управления кэшированием. Это мера предосторожности для контента, к кэшированию которого нет определённых требований.
text/html имеет значение epoch. Это специальное значение, которое отключает кэширование, вследствие чего браузер всегда будет запрашивать актуальное состояние сайта.
text/css (таблицы стилей) и application/javascript (файлы Javascript) имеют значение max. Это значит, что браузер будет кэшировать эти файлы в течение максимально возможного периода времени, значительно уменьшая количество запросов (учитывая, что таких файлов обычно много).
~image/ — регулярное выражение, которое ищет все файлы с MIME-типом image/ (например, image/jpg и image/png). Оно также имеет значение max, поскольку изображений, как и таблиц стилей, на сайтах много. Кэшируя их, браузер уменьшит количество запросов.

Директива expires (включена в модуль headers) настраивает заголовки для управления кэшированием. Она использует значение переменной $expires, указанной в блоке map, благодаря чему заголовки ответа отличаются в зависимости от типа файла.

Сохраните и закройте файл.

Чтобы обновить настройки, перезапустите Nginx:

sudo systemctl restart nginx

4: Тестирование кэширования браузера

Выполните тот же запрос, что и в начале руководства:

curl -I http://localhost/test.html

Время ответа будет отличаться. В выводе вы увидите два новых заголовка ответа

HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:48:53 GMT
Content-Type: text/html
Content-Length: 1024
Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT
Connection: keep-alive
ETag: "57d40685-400"
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Cache-Control: no-cache
Accept-Ranges: bytes

Заголовок Expires показывает дату в прошлом, а Cache-Control имеет значение no-cache,что значит, что браузер должен остоянно запрашивать актуальную версию файла (с помощью заголовка ETag).

Запросите другой файл:

curl -I http://localhost/test.jpg
HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:50:41 GMT
Content-Type: image/jpeg
Content-Length: 1024
Last-Modified: Sat, 10 Sep 2016 13:11:36 GMT
Connection: keep-alive
ETag: "57d40688-400"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes

Как видите, результат отличается. Expires содержит дату в далёком будущем, а Cache-Control имеет значение max-age, которое сообщает браузеру, как долго он может кэшировать файл (в секундах). В данном случае браузер будет кэшировать загруженный файл максимально долго, так что в дальнейшем для загрузки этого изображения браузер будет использовать локальный кэш.

Попробуйте отправить запросы к файлам test.js и test.css, вы должны получить похожий результат.

Из вывода команды curl видно, что кэширование браузера успешно настроено. Кэширование страниц увеличит производительность сайта и уменьшит количество запросов.

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