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

У меня есть системный запуск nginx /php-fpm /лак /wordpress и amazon s3.

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

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

Я не понимаю, почему это делается. Большинство примеров также запускают NginX как веб-сервер. Теперь возникает вопрос: зачем использовать кеш-лак для кэширования этих статических файлов.

Мне гораздо удобнее кэшировать динамические файлы, чтобы php-fpm /mysql не попадались так сильно.

Я прав, или я что-то пропустил здесь?

UPDATE

Я хочу добавить некоторую информацию к вопросу, основанную на ответе.

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

Тем не менее, для меня важнее статический континент . Я нашел ссылку с некоторыми тестами и бенчмарками по различным приложениям кеша и приложениям веб-сервера.

http: //nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

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

-

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

8 голосов | спросил Saif Bechan 20 TueEurope/Moscow2011-12-20T05:01:25+04:00Europe/Moscow12bEurope/MoscowTue, 20 Dec 2011 05:01:25 +0400 2011, 05:01:25

4 ответа


9

Есть несколько преимуществ для лака. Первое, что вы заметили, - это снижение нагрузки на серверный сервер. Как правило, кэширование содержимого, которое генерируется динамически, но редко изменяется (по сравнению с тем, как часто он доступен). Принимая ваш пример Wordpress, большинство страниц, по-видимому, не меняются очень часто, и существуют некоторые плагины, которые существуют, чтобы сделать недействительным кеш-лак при изменении страницы (т. Е. Новое сообщение, изменение, комментарий и т. Д.). Таким образом, вы кешируете неопределенный срок и недействительны при изменении - что приводит к минимальной нагрузке на ваш серверный сервер.

Связанная статья не выдерживает, большинство людей предпочтут, что Varnish будет работать лучше, чем Nginx, если правильно настроить - хотя (и я действительно ненавижу это признавать) - мои собственные тесты, похоже, согласуются с тем, что nginx может быстрее обслуживать статический файл чем лак (к счастью, я не использую лак для этой цели). Я думаю, что проблема в том, что если вы в конечном итоге используете Varnish, вы добавили дополнительный уровень в свою настройку. Передача этого дополнительного слоя на сервер backend всегда будет медленнее, чем просто обслуживание непосредственно из бэкэнд - и именно поэтому разрешение на использование лака может быть быстрее - вы сохраняете шаг. Другое преимущество - на диске. Если вы настраиваете лак для использования malloc, вы вообще не попадаете на диск, что оставляет его доступным для других процессов (и обычно ускоряет работу).

Я думаю, что для того, чтобы действительно измерить производительность, нужен лучший тест. Неоднократно запрашивая один и тот же единственный файл, запускается кеширование файловой системы, которое начинает смещать фокус с самих веб-серверов. Лучшим эталоном будет использование осады с несколькими тысячами случайных статических файлов (возможно, даже из ваших журналов сервера), чтобы имитировать реалистичный трафик. Возможно, хотя, как вы уже упоминали, становится все более распространенным, чтобы выгрузить статический контент в CDN, а это значит, что Varnish, вероятно, не будет служить ему для начала (вы упомянули S3).

В сценарии реального мира вы, скорее всего, приоритезируете использование вашей памяти - динамическое содержимое, поскольку оно является самым дорогим для генерации; затем небольшое статическое содержимое (например, js /css) и, наконец, изображения - вы, вероятно, не будете кэшировать другие носители в памяти, если у вас нет действительно веских оснований для этого. В этом случае, когда Varnish загружает файлы из памяти и nginx загружает их с диска, Varnish, скорее всего, выйдет из nginx (обратите внимание, что кеши nginx предназначены только для проксирования и fastCGI, а те, по умолчанию, основаны на дисках, хотя это можно использовать nginx с memcached).

(Мой быстрый - очень грубый, чтобы не было никакого доверия - тест показал, что nginx (direct) был самым быстрым - назовем его 100%, лак (с malloc) был немного медленнее (около 150%), а nginx позади лака (с пропуском) был самым медленным (около 250%). Это говорит само за себя - все или ничего - добавление дополнительного времени (и обработки) для связи с бэкэндом, просто предполагает, что если вы используете Лак и имеете ОЗУ, чтобы сэкономить, вы можете просто кэшировать все, что можете, и подавать его от лака вместо того, чтобы возвращаться к nginx.)

ответил cyberx86 20 TueEurope/Moscow2011-12-20T07:30:25+04:00Europe/Moscow12bEurope/MoscowTue, 20 Dec 2011 07:30:25 +0400 2011, 07:30:25
1

Я думаю, что вы можете что-то упустить.

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

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

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

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

В вашем фрагменте кода выше вы видите очень типичный фрагмент Varn VCL, который заставляет изображения, css и javascript кэшироваться. По умолчанию, Varnish не будет кэшировать какой-либо запрос с файлом cookie. Логика заключается в том, что если в запросе есть куки-файл, тогда должна быть какая-то причина, по которой серверу нужен этот файл cookie, поэтому он необходим на задней стороне и должен проходить через кеш. На самом деле многие CMS (Drupal, Wordpress и т. Д.) Прикрепляют файлы cookie почти ко всему независимо от того, нужна ли она, или нет, поэтому обычно приходится писать VCL, чтобы удалить куки из содержимого, которое, как известно, является статическим, что, в свою очередь, заставляет лакировать кеш он.

Имеют смысл?

ответил jdw 20 TueEurope/Moscow2011-12-20T05:15:00+04:00Europe/Moscow12bEurope/MoscowTue, 20 Dec 2011 05:15:00 +0400 2011, 05:15:00
1

Для динамического содержимого некоторые виды котировок акций часто меняются часто (обновляется каждую секунду на SaaS server из backend server), но может быть запрошен еще чаще (десятками тысяч subscription clients):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

В этом случае кэширование на SaaS server за секунду обновление от backend servers позволяет удовлетворить запросы десятков тысяч subscription users.

Без кеша на сервере SaaS эта модель просто не работает.

ответил Eli 2 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 02 Sep 2012 18:23:07 +0400 2012, 18:23:07
0

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

Для статических файлов: кэш на жесткий диск Для всего остального: кеш к оперативной памяти.

Это должно дать вам больше информации о том, как реализовать этот сценарий: http://www.getpagespeed.com/server-setup/varnish-static-files-cache

ответил Daniel V. 14 +03002015-10-14T05:59:14+03:00312015bEurope/MoscowWed, 14 Oct 2015 05:59:14 +0300 2015, 05:59:14

Похожие вопросы

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

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132