Как правильно организовать частичное кэширование динамики в nginx?

Question

[Alex Plotnikov]

Задача в следующем, нужно закешировать страницы на уровне nginx, за исключением некоторых блоков, движок wordpress, стек nginx+php-fpm.

причина, огромные нагрузки после 1000req/s , php-fpm начинает грузить проц в 100%. Изменять сам вордпресс, плагины и т.д. практически уже невозможно, устоявшийся сайт с большим трафиком.

Подскажите, это вообще возможно? Если да, то куда копать и где подсмотреть? к сожалению гугл не сильно помог.

Спасибо!

Answer 1

[Борис Сёмов]

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

Но лучше кешировать там, где можно кеш правильно инвалидировать, не тупо по ttl, т.е. на уровне приложения. Решений для кеширования разной степени навороченности для WP масса. Надо правильно выбрать и правильно настроить...

Comments

[Alex Plotnikov]

а как же ssi поддержка в nginx? что мешает "некэшируемое" сложить в папку /nocache сложить туда необходимые блоки, и отключить по ней кэширование?

вот как то так linux.ria.ua/SsiBlocks/src/bin/index.php

[Борис Сёмов]

Alex Plotnikov Например то, что для этого проще будет вообще выкинуть WP?

[Alex Plotnikov]

Борис Сёмов, я просто хочу понять, если у меня есть простая страница, где есть "посты" , и есть блок с (авторизацией/показ ссылки в лс/показ имени пользователя aka динамика). смогу ли я этот блок отдельно через ssi подключить? или это вообще не возможно? в том блоке я допустим подключу wp-load, и сделаю только пару запросов к бд, не нагружая формированием всей страницы бэкенд. такой вариант имеет право на существование?

[Alex Plotnikov]

Или как вариант, всю динамику перенести на js и показывать аякс запросами, которые запретить кэшировать? я правильно понял? объем этих запросов все таки будет дешевле, чем дергать всю динамику.

[Александр Гетманский]

Alex Plotnikov, конечно можно - либо с ssi либо varnish. Varnish более гибко настраивается, и меньше шаманства с кодом, но больше гемороя в настройках, из-за его гибкости. С ssi больше возни с кодом, за-то настроек мало. Вот две ссылки с примером в вакууме:
https://goo.gl/XMzr3T
https://goo.gl/X9jKrE

[Борис Сёмов]

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

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

[Александр Гетманский]

Сам имел дело с Varnish+ESI но на сторое кода был не wordpress, а symfony. Проблем не было, кешировал статические блоки с менее критичной информацией, а блоки с более важной не кешил вовсе.

[Alex Plotnikov]

спасибо друзья, буду пробовать, более менее путь ясен.

[Александр Гетманский]

Борис Сёмов, а кто говорит о пули? Да придется попотеть, но это возможно. И если использовать ESI изменять код придется минимально по сравнению с SSI. Все зависит от контекста, а контекста мы не знаем. Если в каждом блоке встречается ФИО, то конечно кеш будет раздут из-за того, что придется кэширать каждый такой блок. Если же 99% это статика и 1% динамика - то тут да, лучше сразу пулять 1 запрос аяксом. Если же у нас 50% на 50% и динамика разная - где-то персонализированная, а где-то нет - то я бы выбрал Varnish.

[Alex Plotnikov]

Александр Гетманский, 90% статика, 10% динамика, примерно так.

[Борис Сёмов]

Я бы не использовал ни SSI, ни Varnish если бы не писал приложение с нуля, и имел бы полный контроль над ним.
Но и в этом бы случае не использовал, т.к. можно было бы реализовать куда более эффективную стратегию кеширования на стороне приложения.

Varnish почти всегда, в итоге, потраченная без пользы память, которую лучше было бы отдать куда-нибудь ещё.

[Александр Гетманский]

Alex Plotnikov, Varnish либо SSI вам помогут. Нужно понимать, что они придадут скорости приложению за счет обхода рендеринга статики. Динамику же настроить можно так, чтобы она вообще не кэшировалась и тогда решается проблема с раздутостью кэша из-за персонализации. Сложность что моего подхода, что Бориса упирается только в одно - перенос логики вашего динамического блока в отдельный php файл. Плюс, либо настройку кэша на стороне бэка, если выбирать мой вариант, либо настройку кэша и написание js кода, который будет тянуть и рендерить кеш на стороне фронтенда, если выберите вариант Бориса.

[Александр Гетманский]

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

[Борис Сёмов]

Александр Гетманский, В случае применения внешнего кеширования, у вас есть, фактически, только одна стратегия - ttl.
При этом, почти всегда, выгоднее инвалидировать кеш по изменению данных, или возникновению какого-либо события, чем по интервалам времени. А регенирировать в один поток, не конкурентно.
Этого можно достичь на стороне приложения, но нельзя на стороне внешнего кеша. Так что ни к какому "ворожению" это не имеет отношения.

[Александр Гетманский]

Борис Сёмов, внешний кэш можно обновлять не только по ttl, но и используя механизмы инвалидации кеша. Нет, конечно, на стороне приложения тоже должна быть система кэша, но это не панацея. Чаще всего используют обе системы - внешнюю (varnish, ssi, etc) и внутреннюю, что позволяет еще сильнее сократить время отклика и снизить нагрузку.

[Alex Plotnikov]

я пробовал использовать wp super cache, но мне не понравился механизм этот, когда в шаблоне пишешь тег и через хуки на его место ставишь динамику. при чем это не избавило от проблемы php-fpm cpu usage 100% при >1000 юзеров онлайн, которые активно взаимодействуют с сайтом. p.s. ядер на сервере 24, памяти 64гб, ssd диски. slowlog смотрел, все sql запросы вроде быстро проходят, но на пике растет mysqld в 300% и каждый php-fpm в 100%.

[Александр Гетманский]

Alex Plotnikov, я бы рекомендовал замерить скорость рендеринга динамической части приложения и статики. А какая версии php? OpCache используете?

[Alex Plotnikov]

Александр Гетманский, php 7.2, opcahce наверно нет, не уверен. при пиковой нагрузке, в slowlog пишется что страница рендерится по 5-10 сек.

[Alex Plotnikov]

Александр Гетманский, да и еще, много запросов вида select like, то есть активно используется поиск.

[Александр Гетманский]

Alex Plotnikov, 5-10секунд это при пиковой нагрузке? а если в простое? Чтобы проверить установлен OpCache просто выполните команду в консоле сервера php -v, если будет подобная строка:

with Zend OPcache v7.1.14-1+ubuntu16.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies

то OpCache есть.

[Alex Plotnikov]

Александр Гетманский, opcache модуля нет, как выяснилось. в простое не знаю, но до 1000 онлайн юзеров, все вроде хорошо, сервер держит , cpu usage 40-70%. все начинается после определенного предела, когда ежесуточный наплыв приходит трафика.

[Alex Plotnikov]

Александр Гетманский, при обычной загрузке не знаю сколько генерируется страница, т.к. slowlog настроен на 5 sec

[Александр Гетманский]

Alex Plotnikov, я бы на вашем месте замерил скорость работы отдельных блоков - статики и динамики на локальной машине, чтобы иметь представление о том, что дольше рендерится. А также я бы рекомендовал бы выяснить запросы от динамических или статических блоков заставляет mysqld нагружать цп. У вас очень много оперативной памяти, но используется ли она? Сколько при пиковой нагрузке используется памяти на сервере? Может быть, если ее в избытке, стоит произвести тонкую настройку кеша mysql...

[Александр Гетманский]

Поставте opcache :) Думаю, нагрузка частично снизится. Не буду раньше времени вас радовать, но думаю примерно в два раза станет лучше, со стороны php (предположение строю, опираясь на эту статью https://habrahabr.ru/post/264775). А вот проблема с mysqld должна остаться.

[Борис Сёмов]

Opcache просто безусловно нужен - разницу будет видно не вооруженным взглядом... =)

Для поиска есть solr, sphinx и.т.п. - намного эффективнее чем mysql like запросы. Это может очень заметно уменьшить нагрузку, и качество поиска улучшить, кстати. Я не сталкивался, правда, с реализацией поиска WP на этих движках, но наверняка есть готовые решения.

300% mysql, это загрузка всего трёх ядер, что вероятно, не так и много.

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

[Alex Plotnikov]

Если кому интересно, проблема была решена следующим образом: установлен opcache, кэш nginx c ssi, местами вынес логику в js клиентский с запросами на wp-ajax которые nginx не кэширует. теперь сервер на пике потребляет 10% cpu , и LA 2-3.

Answer 2

[Александр Гетманский]

Сам nginx не умеет кешировать (upd: кешировать нужные блоки на страницах), но можно использовать Varnish с ESI для кеширования динамических блоков сайта. Самый простой способ это поставить Varnish перед nginx (тогда Varnish будет на 80 порту, а nginx на любом другом), но чтобы добиться высокой производительности лучше повозиться и настроить связку nginx - Varnish - nginx, что более сложно, но скорее всего даст более желаемый результат в вашем случае.

Comments

[Alex Plotnikov]

а что такое fastcgi_cache тогда, если не кэширование? я тут запутался. про Varnish да, слышал, нужно ознакомиться.

[Александр Гетманский]

Alex Plotnikov, да, вы правы это кеш, но кеш всего ресурса по url которые мы указываем, а не отдельных блоков. Пожалуй, мне стояло это упомянуть в своем ответе.

[Борис Сёмов]

Умеет. Как проксируемые, так и fastcgi запросы.

[Alex Plotnikov]

Александр Гетманский, я вот к ответу выше написал комментарий, подключитесь, если вам не сложно. я про ssi хотел бы услышать ваше мнение в контексте nginx