Добавить кеширование

а оно нужно вообще?
как бы фиды прекрасно кэшируются любым плагином кэширования – страничный кэш все равно будет быстрее чем WP_Object_Cache.

Страничный кеш не спасает при первом обращении к странице и сбрасывается при обновлении записей. Т.е. когда что-то новое в фиде появилось — он грузится долго и в некоторых случаях может сбрасываться по таймауту. А именно появление новой инфы и должно быстро отдаваться Яндексу.

Особенно это актуально для сайтов, которые часто обновляются. Мы пишем много новостей и страничный кеш точно нужно будет обновлять при каждом обращении бота Яндекса.

сколько вы новостей то пишите в день?
10-20-50?
50 записей в ленте должны быстро генерироваться даже на слабеньком vps.

Разбил всего по 20 записей, первая генерация почти минуту занимает: https://tproger.ru/feed/turbo

При этом у нас отдельный железный сервер с 24 ядрами и 64 ГБ памяти.

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

ну у меня на тестовом сервере лента из 300 записей генерируется 30 сек максимум. записи, правда, довольно простые – тестовые, но, тем не менее.

а у вас и правда “железный” сервер.
боюсь у вас там слабое место не проц и память, а mysql – плохо настроен и сконфигурирован. уверен быть не могу, но если бы мне пришлось делать ставку – я бы поставил на базу данных. это всегда узкое место на высоконагруженных проектах.

20 записей генерироваться минуту – такого я себе представить не могу. и да – я посмотрел у вас вторую страницу ленты – около минуты и правда. так быть не должно

А сколько у вас записей в БД?
У меня 160000 записей, лента по 50 генерируется минуту-полторы. Это проблема WP.

А сколько у вас записей в БД?

определенно не столько.
но какая разница, сколько там записей, если выборка идет только 50 записей? WP используют свою обертку для работы с mysql, но ничего сверхъестественного там нет – почти те же прямые запросы.

если вы напрямую в phpmyadmin сделаете выборку в wp_posts 50 произвольных записей – сколько времени это займет? если так же много – беда именно в базе данных.

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

Записей много, вы правы. Спасибо за советы с БД, проверим. Но всё же слабо верится, ведь остальные части проекта работают исправно и довольно быстро, обычный rss2-фид в том числе.

Однако, я бы всё равно добавил 5 строк для кеширование предобработанных записей. Реализовывать быстрее, чем обсуждать, а даже тем, где всё и так быстро, было бы ещё быстрее и с меньшим потреблением ресурсов.

Нет, напрямую выборка молниеносная. Пусть проверят у себя.
У меня всё давно ясно, WP делает множество запросов для генерации одной записи, обходит все теги, категории, комментарии.

Потому я делаю короткие ленты, и обхожу их принудительно, отдаю яндексу только кешированное.

• This reply was modified 6 years, 8 months ago by kgstim.

Однако, я бы всё равно добавил 5 строк для кеширование предобработанных записей.

боюсь, что там не 5 строк выйдет.

Потому я делаю короткие ленты, и обхожу их принудительно, отдаю яндексу только кешированное.

Норм вариант, но несколько обидно, что уже есть хороший плагин, а не хватает всего какой-то мелочи, чтобы он стал отличным ??

боюсь, что там не 5 строк выйдет.

Давайте завтра сделаю, скину вам код. Если сочтёте нужным — включите в свой.

давайте.

В общем, кеширование и правда помогло, время для рендера фида сократилось приблизительно в 10 раз. Правда, не самого контента записи, а <yandex:related>. Запрос похожих записей очень долгий. Поместил его в post meta + в объектный кеш. И обновления когда контент записи обновляют или создаётся новая.

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

Могу скинуть получившийся код.

ага, давайте