Окт
1

Анализ SQL запросов и глюк с 2000 SQL запросами в WordPress

Author admin    Category Полезное     Tags

WordPress SQL запросыВ последний месяц в блоге о дизайне постоянно наблюдались проблемы с загрузкой веб-страниц. При всем при том, что там используется VPS сервер + установлен кэш MaxCache. Для 2к посетителей в сутки этого должно было хватать с головой. Несколько раз совместно с тех.поддержкой пытались решить проблему, однако в итоге периодически сайт «оказывался в дауне». Собственно, сегодня будет история о том, как удалось решить эту проблему, а также как можно провести анализ SQL запросов.

Первым делом я добавил в футер код отображения числа запросов.

<?php if (is_user_logged_in()) { ?>
<?php echo get_num_queries(); ?> запросов за <?php timer_stop(1); ?> секунд. 
<?php } ?>

Как вы уже поняли из заголовка, результат был равен более 2000 запросам SQL к базе данных. Для такой посещаемости, да и вообще для нормального сайта, это чересчур много. Как следствие – проблемы с загрузкой. Для несколько остальных WordPress блогов и обычных сайтов число запросов колебалось от 50 до 80 штук.

Но как узнать что именно приводит к такому большому числу SQL запросов? К счастью мне попалась соответствующая статья с сайта 4remind.ru. Спасибо автору за описание решения проблемы. Я продублирую его для вас здесь + для себя дабы не забыть. По ссылке найдете более детальное описание.

1. Итак, в файле wp-settings.php из корневого каталога WordPress добавляете строку:

define( 'SAVEQUERIES', true );

Она позволяет системе запоминать SQL запросы к базе данных.

2. Дальше в файле footer.php пишем код:

<?php
if ( current_user_can( 'administrator' ) ) {
        global $wpdb;
 
        echo '

########## SQL запросы ##########

';
        echo '';
        echo 'Количество SQL-запросов = ' . sizeof($wpdb->queries);
        echo '
';
 
        $sqlstime = 0;
        foreach ( $wpdb->queries as $qrarr ) {
                $sqlstime += $qrarr[1];
        }
 
        echo '';
        echo 'Затрачено времени = ' . round( $sqlstime, 4 ) . ' секунд';
        echo '

';
 
        foreach ( $wpdb->queries as $qrarr ) {
                echo 'SQL-запрос = ' . $qrarr[0] . '
';
                echo 'Время выполнения = ' . round( $qrarr[1], 4 ) . ' секунд
';
                echo 'Файлы и функции: 
';
                $filesfunc = split( ",", $qrarr[2] );
                foreach ( $filesfunc as $funcs ) {
                        echo '+ ' . $funcs . '
';
                }
                echo '
';
        }
 
        echo '
########## END: SQL запросы ##########

';
}
?>

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

Вот как примерно выглядит результат:

Глюк с 2000 SQL запросами WordPress

Таким образом, вы можете проанализировать сколько времени занимает выполнение того или иного обращения к БД, какой плагин злоупотребляет SQL запросами и т.п. Тем пользователям, кто разбирается в веб-разработке, должно быть полезно.

3. После того как вы закончили анализ SQL запросов обязательно удалите из файла wp-settings.php определенную переменную SAVEQUERIES (закомментировать недостаточно).

…..

Что же касается моего случая, то данный анализ SQL запросов выдал мне ну очень большой список из 2000 разных позиций. Просматривать их все я бы стал очень долго. Поэтому я пошел немного иным путем и начал «традиционный поиск проблемы в WordPress» в шаблоне (убирая сомнительный код) и плагинах (отключая некоторые из них).

1. Первым делом я решил «избавиться» от модуля Simple Tags и моего хака с добавлением миниатюр в Simple Tags для связных постов. Во-первых, плагин довольно старый, во-вторых, я мог допустить ошибку при правке PHP кода. Но нет, отключение плагина ни к чему не привело.

2. После решил убрать из шаблона WP-PostRatings, что также мог нагружать БД. Эффекта не последовало.

3. Дальше я буквально вырезал из шаблона целые куски кода: футер, сайдбар целиком. При этом код анализа SQL запросов все равно показывал 2000 обращений к базе. Теоретически этого быть не могло. Точнее, это значило, что проблема не в шаблоне.

4. Следующий шаг – отключение плагинов. Если быть точным, некоторые модули, например, Broken Link Checker для поиска битых ссылок я убрал заранее, а сейчас добрался и до остальных. Мало ли что там могло заглючить. Однако и эта манипуляция ни к чему не привела.

5. Последний шаг – обновление WordPress. Не хотел к нему прибегать, так как пришлось бы обновлять разные модули, а в код некоторых из них я вносил правки + не хотелось получить несовместимость какого-то плагина с самой последней версией WordPress 4.0.

Вы будете смеяться, но после обновление WordPress запросов к БД опять стало 60-80. Проблема исчезла. Мистика, как говорится, в таких случаях. Нужно, наверное, было с этого начинать. Автоматическая процедура апдейта заняла считанные минуты, тогда как поиск решения забрал у меня парочку часов. Притом, что никаких изменений с системой, плагинами, шаблоном до появлениях глюка с 2000 SQL запросами я не проводил. Как бы там ни было, теперь вы знаете как можно решить подобную проблему и как искать вероятную причину поломки.



Прокомментировать

Новые шаблоны и статьи

Рубрики

Популярные шаблоны

Мы помогаем детям


KosynokBannerNetwork