Как исправить более высокий процессор, использование памяти для сайта WordPress? Руководство по оптимизации, приемы htaccess и Disqus

Мы размещены на полуоткрытом хостинге Squidix, и это pretty reliable , Мы с ними никогда не сталкивались. Но недавно мы заметили более высокую загрузку процессора и памяти на нашем сервере.

Там может быть multiple reasons для более высокой загрузки процессора и памяти:

1. Crunchify является зрелым сайтом и начал получать очень высокий трафик
2. Пара последних обновлений плагинов
3. Недавно обновление темы и пользовательская модификация, которая включает в себя пользовательский тип сообщения и многое другое.
4. может быть, что-то еще…

Давайте начнем —

Контрольная точка-1: использование памяти и процессора

Вот определение проблемы. Почему так много памяти и процессора? Оформить заказ ниже ~50% CPU usage а также ~4GB Memory usage граф.

Check Point-2: Процессы входа

Однажды мы посмотрели на наши cPanel Затем мы заметили такое же большое количество процессов ввода.

Шутки в сторону?? ~228 entry process вовремя??? Bluehost и Hostgator по умолчанию позволяют maximum 25 entry процесс за один раз сравнить с Squidix allows 400 , В этом случае вы не смогли бы выжить с хостингом Bluehost или Hostgator.

Точка здесь ==> ~ 228 процессов входа toooo much ,

Статистика проверки (до):

Чтобы исправить это более высокое использование процессоров, памяти и ввода WordPress , мы начали искать все возможности.

Мера предосторожности Шаг-1

Сначала мы устранили higher traffic pattern в качестве причины, потому что мы используем плагин WP Super Cache WordPress, и он очень хорошо справляется с этой ситуацией. На самом деле — страница загружается in near half a second ,

С ~16 millions calls per month мы не увидели ухудшения показателей загрузки сайта. Давайте двигаться дальше.

Шаг предосторожности-2

Любой недавно plugin а также theme Обновить?

Хм … эти обновления были от очень надежного участника WordPress, и, потратив значительное количество времени, мы также исключили эту возможность. У нас есть локальные настройки WordPress с использованием MAMP и после disabling а также enabling те плагины, которые мы не заметили, время загрузки страницы или более высокая проблема с процессором.

Шаг предосторожности 3

Теперь я остался только с моим last doubt о плагине Disqus , Я гуглил его и нашел пару очень интересных тем о higher CPU usage а также Disqus ,

На Crunchify у нас есть Disqus Sync enabled by default ,

Теперь подумайте об этом сценарии:

Если у вас нормальный трафик, например, около 2000 активных пользователей, то задание синхронизации Disqus также выполняется ~ 2000 раз в данный момент времени, и это not good ,

1 Sync job = 1 Cron job call , И наконец мы нашли актуальную проблему.

Как устранить проблему с высокой загрузкой ЦП Disqus, вызванную заданием синхронизации dsq_sync_forum?

Решение-1.

Шаг 1

1. Идти к Plugins -> Editor
2. Выберите плагин Disqus Comment System из поля со списком
3. Поиск строки 514 wp_schedule_single_event($ts, 'dsq_sync_forum');
4. Замените его этим блоком кода и save файл.

Шаг 2

1. Идти к Comments -> Disqus
2. Нажмите на Plugin Settings
3. Снимите флажок для Disable automated comment importing
4. Save изменения

Итак, как синхронизировать комментарии сейчас?

Теперь после этого всякий раз, когда вы хотите синхронизировать комментарии Disqus с базой данных WordPress, просто установите флажок выше и сохраните настройки. Все комментарии будут импортированы в вашу базу данных в течение 10 минут.

Решение-2. Как отключить wp-cron.php с помощью трюка .htaccess?

1. Загрузить Disqus только на onClick event — Это означает, что пользователь должен нажать на Load Comment button загрузить комментарии. Но есть некоторые disadvantages ,
   1. Если посетитель видит комментарии правильно поданными им, он может с большей вероятностью их прочтет.
   2. Вклад в раздел комментариев также более вероятен, если раздел комментариев виден по умолчанию.
2. Блокируйте синхронизацию Disqus при каждой загрузке страницы, добавив .htaccess править.
   • Я попробовал этот подход, и он тоже работал.

Чтобы достичь point-2 выше я добавлю ниже mod rewrite rules в .htaccess файл.

В основном приведенный выше код заблокирует все wp-cron.php jobs

NOTE: мы недавно добавили url pattern который требуется для всех функций WordPress Embed и ver pattern который требуется для загрузки style.css или другие файлы с номером версии в качестве параметра.

Давайте разберемся в этом блоке:

• Игнорировать всю строку запроса в URL и перенаправить на URL вашего блога
• Если строка запроса содержит ?s= а также ?q= тогда только это позволят. Образец:
  • https://crunchify.com/search/?q=wp%20super%20cache
  • https://crunchify.com/?s=wordpress
• Игнорируйте это правило, если URL содержит wp-admin

После включения вышеупомянутого правила я увидел significant improvement на использование памяти и процессора и it's nearly zero , Также — entry process был почти достигнут zero(0) , Это означает, что посетители почти все время обслуживали кэшированную страницу.

Этот пост также поможет вам, если у вас есть проблемы ниже, и он является частью советов по оптимизации WordPress .

• WordPress Высокая загрузка процессора?
• WordPress High Использование памяти ?
• Исправление использования процессора в WordPress
• WordPress чрезмерное использование ресурсов
• WordPress проблема использования процессора
• Исправлена проблема с высокой загрузкой процессора в dsq_sync_forum
• плагин WordPress использование процессора
• уменьшить использование процессора wp
• Как контролировать и уменьшить использование памяти WordPress
• превышено использование памяти WordPress
• оптимизация использования памяти WordPress
• Использование памяти плагина WordPress Disqus

Проверьте разницу (после):

Update: 15 июля 2017 года мы перешли на стандартную систему комментариев WordPress . Получить представление, почему на этом посту