Wordpress медленный мета-запрос на 1000+ сообщений

Question

Задача

WordPress Meta Query не так гибок, как обычный запрос в отношении выбора дат. WP Query может выбирать даты по номеру месяца, имени дня недели и многим другим вариантам, которые подходят для того, что мне нужно.

ACF Поля

Дата Событие, Дата окончания, дата смерти (некоторые Taxonomies), «Repeat (Навсегда, До)»

В принципе я построил мета запрос, который получит даты, которые приземляются на сегодня , или это может быть повторяющимся (поэтому Daily, Monthly и Weekly), а затем я фильтрую все через PHP, сравнивая его с именем недели недели для еженедельного и числом дней в месяц. Я также проверяю, чтобы все повторяющиеся сообщения не отображались, когда они не должны были быть.

Вот мета массив запросов я использую дату хранится в Ymd:

'relation' => 'OR', [ 'key' => 'event_date', 'value' => $date->format('md'), 'compare' => 'LIKE', 'type' => 'numeric' ], [ 'key' => 'death_date', 'value' => $date->format('md'), 'compare' => 'LIKE', 'type' => 'numeric' ], [ 'key' => 'how_often', 'value' => array('Daily', 'Monthly', 'Weekly'), 'compare' => 'IN' ] 

Чтобы поставить его в перспективе, этот запрос будет получать ~ 130 сообщений, в том числе мета- и других связанных с ними запросов, и после того, как PHP запустил фильтрацию сообщений (что занимает 2,5 секунды!), я оставил 78 сообщений.

Что я Пробовал

Я попытался ограничить запрос еще будучи очень специфичным для повторяющихся сообщений, как с указанием, что event_date должен быть <= запрашиваемой дата, и либо end_date является >= запрашиваемыми дата или мета forever установлено на forever. Однако это не поможет, когда дело доходит до ежемесячного или недельного повторения, поскольку у меня нет возможности правильно рассчитать эти даты. Я уже загрузил более 10 тыс. Сообщений и использовал эту обычную метаструктуру. Он работал нормально с примерно 1200 сообщениями, после чего сайт стал очень вялым. страница с 78 сообщениями в настоящее время занимает около 8-12 секунд для загрузки первого байта.

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

Вопросы

1. Каков наилучший способ идти о получении ежемесячных и еженедельных повторяющихся сообщений через SQL?
2. Будет ли это на самом деле ускорить загрузку моей страницы или это замедлит ее? Очевидно, что с большим количеством сообщений появляется больше запросов для мета, но разбиение на страницы на самом деле не является вариантом для этого приложения.

Answer 1

1. У меня нет решения, чтобы ускорить запрос. В WordPress большие объемы данных выделяют времена, которые замедляют загрузку/запросы. независимо от того, что вы сделаете, все равно будет больше 2 секунд +. (это уже много).

2. О опции кеша, вы можете построить робота, который посетит все ссылки, поскольку диапазон дат известен, а затем проблема решена.Что-то вроде: (Это только пример)

   for($startdate ; $startDate < $endDate ; $startDate=addDayToDate($startDate)){ 
        file_get_contents($url.$startDate); 
   } 
   

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

Answer 2

Для стольких сообщений это действительно не должно занимать 2,5 секунды. Вам нужно взглянуть на свой хостинг. Все, на что нужно обратить внимание, включает использование вашей памяти на этой странице - для того, чтобы PHP перебирал более 130 элементов и отфильтровывал до 75 сообщений, он должен занимать несколько миллисекунд.

Если вы используете Apache, подумайте о переключении на Nginx - это намного облегчает использование памяти, и если это замедление на основе памяти, вы обнаружите значительное ускорение скорости.