Стоит ли злоупотреблять Transients API?
Сейчас пишу большой проект-соцсеть на ВП и возник вопрос по транзитным опциям. Дело в том, что я никогда их не использовал до этого и могу не знать всех "подводных камней".
Пример: у меня пользователи на сайте реализованы через кастомный тип записей, соответсвенно, когда юзер логинится, я делаю стандартный WP_Query. Стоит ли ставить transient на каждого пользователя с именем trans_user_%id%? Так же очень часто у меня есть запросы к get_post_meta() - стоит ли каждый такой запрос кешировать или это не сильно сказывается на производительности?
Ты мыслишь не в том направлении по отношению к транзитным опциям и что в них нужно хранить... В транзитные опции можно и нужно совать, HTTP запросы на другие сайты из PHP, очень сложные sql запросы для больших таблиц с кучей параметров, например wp_query запрос для получения записей по куче условий с метаполями в таблицу с 50к+ записей...
А для всего остального врубай объектный кэш, на redis, memcached, memcache и т.д. Тогда все твоим метаполя и прочее будет автоматом браться из кэша статичного (вообще никаких sql запросов), данные юзеров, данные постов, комментов все опции сайта и т.д.
Кэш метаполей в самом WP очень хорошо прописан, лучше не сделаешь...
Кроме того если объектный кэш не включен, то все транзиты пишутся в БД в wp_options - ну вот представь насуешь ты туда кучу кэша на 100МБ, и ВП каждый раз будет грузить это все в память... Дурдом...
Далее, дла каждого транзита создается 2 записи в wp_options. По моему это не хорошо.
Я бы вообще не рекомендовал юзать Transients API кроме случаев когда это реально удобно... На моей практике всегда можно обойтись без них и с лучшей логикой. Изучи объектный кэш и прям туда все кэшируй. А принципы его работы можно менять налету, разными подходами и плагинами... Например кэшировать в файлы, или в оперативку (в последнее время в оперативку модно потому что быстро).
При включенном объектном кэше, все временные опции (транзиты) пишутся туда...
Спасибо за развёрнутый ответ. Я сейчас погуглил по этим моментам и многие статьи сводятся к тому, что "устанавливайте плагины кеширования и нет проблем", просто я очень не люблю плагины и стараюсь всё сделать "под себя". Я абсолютно не разбираюсь в серверной настройке и разных memcahed и т.п. С какой стороны начать изучать эти вопросы в контексте WP? И достопны ли все эти "кеширования в оперативку" на хостингах, а не на личных серверах?
На одной из статей наткнулся на совет использовать плагин Batcache, мол, он используется самим wordpress.com
Вот здесь https://codeseller.ru/post-group/kak-ya-obnovil-php-do-7-versii-i-wordpress/ человек поделился как он организовал связку PHP 7.0.15 + opcache + memcached и какой крутой результат получил. Все же объектное кеширование вещь крутая. Как он написал - он тоже не силен в серверах и их настройках
Batcache не пользовался, не знаю, но тоже читал, ему модуль Memcached нужен на сервере.
Проще тебе будет узнать какой модуль кэширования есть на сервере: Memcache, Memcached, APC, XCache, Redis и т.д. и установить один из подходящих плагинов.
Как правило это даже не плагины в привычном понимании - это просто класс заменяющий базовый объектный кэш WP на другой подстроенный под модуль кэша на сервере...
Всякие кнопки сброса кэша возможно нужно будет самому написать на базе wp_cache_flush(). Все фукнции работы с таким кэшем у меня описаны, см. функции object-cache
Круто, тогда когда дойду до стадии кеширования проекта, то буду тестить и скину результаты
Привет! Нет смысла выбирать между Transients и get_post_meta - они обе обращаются к БД за инфой. Transients обычно используется для хранения инфы, которая долго парсится, к примеру проверка обновлений движка, обновление инфы по курсам валют с других сайтов. Просто спарсили курсы валют, к примеру, и дёргаете их теперь со своей базы - а этот процесс намного быстрее, чем обращение к другому сайту. Ну и в Transients сразу заложен механизм устаревания информации, с помощью которого можно понять, надо снова делать запрос на сторонний сайт (или другие действия), или пока пользоваться та что есть. А get_post_meta - это просто обычное хранение информации. Образно говоря.
Ну да, get_post_meta() - это один запрос, а если делать 10 запросов и сохранять их данные в одну переменную, которую записывать в transient. Тут получается что вместо 10 запросов получаем 1. PROFIT?
Ну и про юзеров вопрос: вот залогинилось 100 человек и ходят по сайту. Каждый переход по страницам - цикл WP_Query + несколько get_post_meta(). Итого выходит порядка 10-20 запросов к БД помноженное на количество активных пользователей. А можно разбить на 2 - transient с результатом WP_Query и с результатом всех метаполей.
Начнём с того, что запрос get_post_meta очень быстрый, тысячные секунды. А ещё в произвольных полях также можно хранить массивы, объекты. В общем, это тоже самое, что и transient, только в них не предусмотрен механизм проверки "старости" данных. Поэтому получение информации из произвольного поля быстрее, чем из transient, так как ничего не проверяется. Вы выбирайте в данном случае тот способ, который вам удобнее.
Хм, интересное замечание, спасибо. Т.е. WP_Query лучше кешировать, а произвольные меты тянуть вживую, если их немного (если 10+, то очевидно лучше кешировать)
Я бы на твоём месте не заморачивался с этим, экономия на спичках. Во всяком случае проведи тесты, чтобы понять, стоит ли игра свеч или нет. Также стоит копнуть в сторону объектного кеша.
Ну на самом деле проект большой - тематическая соц.сеть, где будет 10к уников в сутки и ещё больше во время разных ивентов, так что каждая доля секунды будет важна.
Тогда тесты, тесты и ещё раз тесты
ничего лучше тестов не расскажет, как лучше
Все правильно сказано.
И нам напишите результаты - будет интересно почитать.
Может Kama даже пост опубликует с Вашими тестами.
Спасибо, я постараюсь не забыть, когда проект будет в какой-либо самодостаточной альфе.