ИТ Блог. Разработка сайтов на CMS Wordpress
На каждой странице интерфейса вашего веб-сайта WordPress загрузит ‘autoloaded’ параметры в объект PHP.
Как работает WordPress, есть варианты для плагинов, хранящихся в таблице wp_options. В этой таблице есть столбец под названием ‘autoloaded’, и любые параметры со значением “yes” в столбце “autoloaded” загружаются в объект при каждой загрузке страницы.
Эффект, который это оказывает на ваш сайт, заключается в увеличении количества потребляемого процессорного времени PHP, как вы можете видеть на этом скриншоте – обратите внимание, что время SQL невелико, но общее время велико. Есть 3 вещи, напрямую влияющие на скорость генерации страниц в WordPress: время SQL, время PHP и вызовы API.
Первый устанавливаемый плагин называется Query Monitor. Установите его, загрузите любую из своих интерфейсных страниц и посмотрите на новую панель Query Monitor.
На примере выше вы можете видеть, что для вызовов SQL используется 0,2815 секунды. При отсутствии вызовов API оставшееся время составляет процессорное время PHP, что означает, что процессорное время PHP тратит 3,01 секунды на создание этой страницы. Это * много *.
Чтобы подтвердить, что вы не используете вызовы API, щелкните панель монитора запросов, а затем щелкните ссылку “Вызовы HTTP API” слева в нижнем колонтитуле монитора запросов, который появляется.
По умолчанию WordPress сохраняет переходные процессы в вашей таблице wp_options с автозагрузкой, установленной на ‘yes’. Итак, основным стимулом здесь является установка Redis object cache на вашем сервере и плагина Redis object cache от Till Krüss. При установке Redis убедитесь, что она настроена как система хранения в оперативной памяти, а не для сохранения элементов на диске.
После установки плагина Redis и плагина активируйте плагин, затем перейдите в настройки плагина и включите кэш объектов.
Теперь дважды обновите страницу проблемы – один раз, чтобы заполнить кэш объектов, второй раз, чтобы увидеть последствия.
При установке Redis ваши переходные процессы теперь сохраняются в вашем объектном кэше, но ваши старые переходные процессы все еще находятся в wp_options. Чтобы исправить это, запустите следующий SQL:
delete from wp_options where autoload = 'yes' and option_name like '_transient%';
После того, как вы это сделаете, вы можете перепроверить, по-прежнему ли Scalability Pro выдает вам предупреждение о производительности. Если это так, вам нужно найти виновника вашего плагина. Запустите эту SQL-команду:
select left(option_name,15) option_name, count( * ) total from wp_options where autoload = 'yes' group by left(option_name,15) order by total desc limit 20;
Для запуска SQL вы можете использовать плагин SQL Executioner или mysql из командной строки вашего сервера или phpMyAdmin.
С помощью приведенного выше запроса вы хотите найти, для каких плагинов установлена автозагрузка 100 или 1000 записей. Как только вы выполните приведенный выше запрос, он выдаст вам указание источника wp_options, для которых установлена автозагрузка. Например, вы можете обнаружить, что все 20 лучших записей взяты из определенного плагина. Каждый плагин, как правило, добавляет в префикс option_name название своего плагина. Тогда вы знаете, где вы можете удалить их или переключить их на автозагрузку = ‘no’.
Если вы не нашли ничего существенного, в вашей таблице wp_options могут быть большие записи. Некоторые плагины хранят много МБ данных в wp_options, когда они действительно не должны. Даже если вы используете Redis или Memcached, это означает, что, когда WordPress получает/сохраняет все параметры, читается/записывается большой объем данных.
Чтобы узнать, не возникла ли у вас эта проблема, запустите этот запрос:
select left(option_name,15) option_name, autoload, sum(length(option_value)) totalsize from wp_options group by left(option_name,15), autoload order by totalsize desc;
С помощью этого запроса просмотрите первые несколько записей и посмотрите, на порядки ли они больше, чем последующие записи. Если это так, это замедляет работу сайтов, даже если используется Redis.
Теперь вы хотите либо удалить эти избыточные параметры, либо остановить их автозагрузку. Существует несколько методов:
Чтобы отключить автозагрузку, вам нужно знать префикс изменяемых параметров плагина. Часто плагины, которые должны запускаться только в wp-admin, будут иметь параметры автоматической загрузки, что безумно глупо. Мы видели плагины sitemap, почтовые плагины и другие плагины администратора со 100 или 1000 параметрами, настроенными на автозагрузку. Итак, найдите префиксы, которые вы хотите отключить, а затем вы можете временно отключить автозагрузку с помощью:
update wp_options set autoload = 'wpi' where option_name like 'badpluginprefix%' and autoload = 'yes';
Этот параметр безопасен, потому что параметры останутся в вашей базе данных и будут доступны для соответствующего плагина, они просто не будут загружаться автоматически на каждой странице.
Как только вы отключите автозагрузку для своих плагинов с плохим поведением, протестируйте свои интерфейсные страницы и убедитесь, что у вас улучшилась скорость.
Чтобы отменить изменения, если вам нужно:
update wp_options set autoload = 'yes' where autoload = 'wpi';
Итак, по сути, вы запустите SQL-команду выше, чтобы определить, какие option_names установлены неправильно – вам нужно решить, нужны они или нет. Часто вы должны знать, основываясь на названии плагина, нужны ли ему опции, загружаемые на каждой отдельной странице, или он используется только изредка.
Затем измените значение автозагрузка на любое другое, кроме ‘yes’, и они больше не будут загружаться автоматически.
Если у вас более 1000 параметров, настроенных на автозагрузку, это обычно увеличивает загрузку страницы на 0,5 секунды (TTFB). Итак, если у вас 5000 или больше, то у вас будет действительно медленный сайт на каждой странице. Исправление параметров автоматической загрузки повышает скорость для каждой отдельной страницы во внешнем интерфейсе вашего сайта.
(2 оценок, среднее: 5,00 из 5)
Загрузка...
