Intereting Posts

Как оптимизировать сайт WP для миллионов сообщений

Я работаю над веб-сайтом для компании, которая, скорее всего, создаст миллионы сообщений через настраиваемый тип сообщений. Это молитвы, поэтому в основном пользователь на переднем конце просто передает короткую фразу через форму. Все, о чем заботится компания, – это содержание сообщения и дата публикации. Сайт еще не запущен, и у них уже более 120 000 должностей, поэтому я серьезно, когда говорю миллионы.

Итак, несколько вопросов оптимизации:

  1. Предположим, у меня есть категория 'featured' в настраиваемом типе сообщений, который содержит 500 000 сообщений. В этой категории есть только 500 сообщений. Если я создам запрос для избранных сообщений, могу ли я запросить все 500 000 сообщений или всего 500? Что делать, если я хочу отображать только десять последних опубликованных сообщений?
  2. При сохранении этого настраиваемого типа сообщений в базе данных есть ли какие-либо вещи, которые я могу сделать, чтобы сократить ресурсы сервера, тем более, что единственное, что действительно необходимо, – это содержание сообщения и даты?
  3. Должен ли я использовать собственный тип сообщений? Мне это нравится в принципе, потому что он хорошо интегрирован в администратор WordPress, но если есть существенные недостатки в производительности, я полагаю, что могу сделать что-то другое.

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

Solutions Collecting From Web of "Как оптимизировать сайт WP для миллионов сообщений"

1. Задайте запрос перед запуском WP_Query

Это, по-видимому, самое важное, что нужно помнить при попытке свести запросы к базе данных до минимума, так как единственная возможность изменить запрос – это, конечно же, до того, как он будет запущен в базе данных SQL.

Обычные запросы
Для обычного запроса WordPress использует функцию wp() , которая в свою очередь вызывает $wp->main( $query_vars ) . «Is_ variables» из условных тегов устанавливаются перед передачей их в WP_Query->get_posts() , которая преобразует его в запрос базы данных MySQL и, наконец, сохраняет их в объекте $ wp_query. Можно фильтровать запрос до его фактического запуска в базе данных SQL .

Действие pre_get_posts перехватывает этот процесс, позволяя вам изменить запрос до его передачи в WP_Query->get_posts() .

Например, если вы хотите отфильтровать запрос для сообщений в категории «избранные», вы должны использовать add_action( 'pre_get_posts', 'your_function_name' ); и in_category условный тег your_function_name в your_function_name .

 function your_function_name( $query ) { if ( $query->in_category( 'featured' ) && $query->is_main_query() ) { // Replace 123 with the category ID of the featured category. $query->set( 'cat', '123' ); } } add_action( 'pre_get_posts', 'your_function_name' ); 

См. API плагинов / Справочник по действию / до получения сообщений «WordPress Codex

Запросы страниц
Что касается шаблонов страниц, таких как страница архива для категории «признакам», условные теги не будут работать с фильтром pre_get_posts . Например, вы не можете использовать is_category для проверки страницы архива, поскольку WP_Query не запущен.

Вместо этого вам придется изменить основной запрос для запросов страниц с помощью new WP_Query который будет выглядеть примерно так: $query = new WP_Query( 'cat=123' ); , Это запускает запрос с соответствующим набором аргументов с самого начала.

См. Описание класса / запрос WP «WordPress Codex

2. Сохранение базы данных

Вы можете использовать фильтр wp_insert_post_data гарантирующий, что в wp_insert_post_data только $ data, относящиеся к вашему пользовательскому типу wp_insert_post . Обязательно включите условный оператор, чтобы проверить свой пользовательский тип сообщения.
API плагинов / Справочник по фильтру / wp insert post data «WordPress Codex

Этот hook wp_insert_post функцией wp_insert_post , которая вызывается wp_update_post, когда вы обновляете свой собственный тип сообщения, обычно, сохраняя черновик или публикуя сообщение.

Вы должны будете сравнить его самостоятельно, хотя я не могу лично говорить о важности оптимизации сокращения данных, которые обновляются в базе данных.

3. Не влияют ли пользовательские типы сообщений на производительность?

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

Раньше была проблема с производительностью, связанная с структурой permalink, которая вызывала у нее хиты, когда она начиналась с текста вместо числа. 3 Это было особенно неприятно для сайтов, на которых размещено большое количество страниц, но было решено с WordPress версии 3.3.

Я только воспитываю permalinks здесь, потому что slug обычно является первой частью структуры permalink, которая может повлиять или не повлиять на производительность до версии 3.3. Помимо этого, я не знаю о каких-либо проблемах с производительностью, возникающих при использовании пользовательских типов сообщений.

Другие параметры производительности

Перепады
Это не замена для минимального количества запросов в вашем коде, но вы можете использовать set_transient для хранения запросов в течение некоторого времени, чтобы новые запросы не были необходимы. Вот пример, используемый в сообщении Дэйва Клементса . Кроме того, обратите внимание, что он рекомендует добавлять действие save_post для удаления переходного процесса в любое время, когда данный тип сообщения обновляется.

 <?php // IN THE SPOTLIGHT QUERY if( false === ( $its_query = get_transient( 'its_query' ) ) ) { $pttimestamp = time() + get_option('gmt_offset') * 60*60; $its_query = new WP_Query( array( 'post_type' => 'spotlight', 'posts_per_page' => 1, 'post__not_in' => $do_not_duplicate, 'meta_query' => array( array( 'key' => '_hpc_spotlight_end_time', 'value' => $pttimestamp, 'compare' => '>' ) ) ) ); set_transient( 'its_query', $its_query, 60*60*4 ); } if( have_posts() ) { // HIDE SECTION IF NO CURRENT ITS FEATURE ?> // LOOP GOES HERE: NOT IMPORTANT TO EXAMPLE <?php } ?> 

Дополнительная оптимизация запросов
У Томаса Гриффина есть несколько хороших советов в его учебнике по оптимизации WordPress . Вот краткий список его предложений:

  • Установите 'cache_results' => false в одноразовых запросах, если ваш сервер не использует постоянное кэширование, такое как Memcached. Одноразовые запросы описываются как «запросы, которые используются для отображения небольших объемов данных. Возможно, вы просто хотите отображать связанные заголовки сообщений, относящиеся к текущему сообщению, или вы можете отобразить раскрывающийся список сообщений для выбора конкретная настройка параметров ".

    Его пример: $query = get_posts( array( 'posts_per_page' => 1, 'cache_results' => false ) );

  • Установите 'no_found_rows' => true где разбиение на страницы не требуется. Это будет «обходить MySQL, подсчитывая результаты, чтобы увидеть, нужна ли нам разбивка на страницы или нет».

    Его пример: $query = new WP_Query( array( 'posts_per_page' => 1, 'no_found_rows' => true ) );

  • Запрос для почтовых идентификаторов, только если это все, что вам нужно 'fields' => 'ids' в get_posts . Это должно значительно сократить объем возвращаемых данных, что довольно много за сообщение, если вы посмотрите на описание базы данных «WordPress Codex

    Его пример: $query = get_posts( array( 'posts_per_page' => 1, 'fields' => 'ids' ) );

В дополнение к этой последней подсказке те же рассуждения могут применяться, когда вам нужно только одно или несколько полей сообщений, используя get_post_field .

Необходимо иметь четкое представление о том, как работает запрос. Чем более конкретным вы можете быть с вашими запросами, тем меньше работы вы будете требовать от своей базы данных SQL. Это означает, что существует огромное количество возможностей для управления запросами базы данных. Будьте осторожны с пользовательскими запросами, где они работают (это страница администратора?), Используйте правильную санитацию в прямых запросах и пытайтесь использовать собственные функции WordPress, где она позволяет достичь той же производительности.

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

В общем, по спецификациям MYSQL не должно быть никаких проблем с объемом данных. Конечно, поиск данных даже с лучшими алгоритмами будет медленнее, а с гораздо меньшими таблицами, но решение для этого – простой и более сильный процессор.

Возможно, вам захочется оптимизировать, как хранятся метаданные (например, не хранить данные, связанные с ping), но это зависит от того, что именно вы делаете, и в конечном итоге вам может потребоваться более сильный процессор, поэтому, возможно, не стоит вашей проблемы ,