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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

я пробовал использовать 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 используете?

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

Александр Гетманский, да и еще, много запросов вида 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 есть.

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

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

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

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

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

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

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

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

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

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

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

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

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