Скорость выполнения запросов

Аватар пользователя _аlex_ _аlex_ 19 июня 2012 в 0:06

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

От чего зависит скорость генерации страницы, а конкретно скорость выполнения запросов mySQL? Выключил в движке и на сервере все возможные оптимизации, но не могу понять, почему первая загрузка страницы происходит долго, а последующие загрузки той же страницы - в несколько раз быстрее. Включил вывод запросов в devel. Количество запросов везде одинаковое. Но скорость исполнения каждого запроса при первой загрузке и при последующих сильно отличаются. Меня же как-раз не устраивает скорость исполнения первого запроса, и хочется иметь возможность производить замеры без постоянной перезагрузки сервера (после перезагрузки сервера - загрузка страницы происходит также долго, как в первый раз).

Комментарии

Аватар пользователя _аlex_ _аlex_ 19 июня 2012 в 0:27

Да, сервер на апаче - denwer (в конфигурации по-умолчанию произведены незначительные в рамках данного вопроса изменения). MySQL - 5.1.4

Аватар пользователя _аlex_ _аlex_ 19 июня 2012 в 10:58

inza wrote:
Сколько модулей подключено и какие?

Включено около 30 дополнительных модулей. Из тяжелых активно используется fields и views. К объему памяти на генерацию страниц притензий пока нет. Кеширующих модулей нет. Во вьюс кеши выключены, в модуле devel выставлена опция для чистки кешей для каждой страницы.
Не думаю, что проблема в количестве модулей, либо в конкретном модуле.

Аватар пользователя sg85 sg85 19 июня 2012 в 7:35

Просто общая информация

"_аlex_" wrote:
От чего зависит скорость генерации страницы

Есть понятие время выполнения запросов к бд(обычно самое долгое, зависит от сложности БД, её объема и сложности запросов) и время отрисовки страницы, зависящее от кода PHP(самое тормозное в нем регулярные выражения, кучи циклов и т.д., если сами там велосипедов не изобретали, то обычно время минимальное), во вьювс, к примеру, это показано наглядно, и у меня как-то общее время генерации вьюхи достигало 90 секунд(т.е. вылет по таймауту), кое-какими манипуляциями над запросом(через апи вьювса) было уменьшено до 0.1 секунды без кэширования)
"_аlex_" wrote:
почему первая загрузка страницы происходит долго, а последующие загрузки той же страницы - в несколько раз быстрее.

в 1й раз у Вас страница отрисовывается без кеширования, 2й раз идет из кеша
"_аlex_" wrote:
Количество запросов везде одинаковое. Но скорость исполнения каждого запроса при первой загрузке и при последующих сильно отличаются.

так же не забывайте что SQL запросы так же кешируются самой СУБД.
"_аlex_" wrote:
(после перезагрузки сервера - загрузка страницы происходит также долго, как в первый раз).

Видимо потому что при этом чистится кэш
"inza" wrote:
Сколько модулей подключено и какие?

Я так понимаю человеку, важно получить прирост производительности в секунднах, а не в наносекундах

Аватар пользователя _аlex_ _аlex_ 19 июня 2012 в 10:49

sg85 wrote:
...во вьювс, к примеру, это показано наглядно, и у меня как-то общее время генерации вьюхи достигало 90 секунд(т.е. вылет по таймауту), кое-какими манипуляциями над запросом(через апи вьювса) было уменьшено до 0.1 секунды без кэширования)

Собственно вьюсом страница и генерируется. Подскажите пожалуйста, куда копать для оптимизации запросов во вьюс. Пока информации по этому вопросу у меня крайне мало (понятно что оптимизировать надо, но не понятно как).
sg85 wrote:
в 1й раз у Вас страница отрисовывается без кеширования, 2й раз идет из кеша

sg85 wrote:
так же не забывайте что SQL запросы так же кешируются самой СУБД.

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

Аватар пользователя sg85 sg85 19 июня 2012 в 7:54

"inza" wrote:
Достаточно нескольких тяжелых модулей, и о нано секундах можно будет забыть, и переходить к измерению скорости при первой загрузки страницы в долях минуты.

И что же такое в Вашем понимании "тяжелые" модули?) Views? да... админка там тяжелая, но простых юзеров в неё не пускают обычно, сами представления медленнее чем свои модули, разница как раз в наносекундах. Какой нибудь уберкарт? там тяжесть скорее из-за кучи лишьнего хлама, которая просто никогда не будет использоваться на сайте, Devel? ага, тяжелый, однако кроме админа обычно его никто и не видит + на работающем сайте он отключен.

Аватар пользователя natbampo natbampo 19 июня 2012 в 11:05

"_аlex_" wrote:
в модуле devel выставлена опция для чистки кешей для каждой страницы

что это опция такая? Эта - "Rebuild the theme registry on every page load "?

Аватар пользователя _аlex_ _аlex_ 19 июня 2012 в 11:33

natbampo wrote:
что это опция такая? Эта - "Rebuild the theme registry on every page load "?

Да. Думаю, кроме кеша форм и тем (обе чистятся по данной опции), в моей сборке других кешей нет (кеш вьюсов отключен, специальных модулей кеширования не установлено). Может быть остается кеш меню и что-то еще на уровне ядра, но меня это не сильно волнует, поскольку количество запросов по данным devel не отличается при первой и последующих загрузках.

Аватар пользователя natbampo natbampo 19 июня 2012 в 12:01

"_аlex_" wrote:
Да

Эта галка должна быть отключена при тестах на производительность.

Аватар пользователя _аlex_ _аlex_ 19 июня 2012 в 12:06

natbampo wrote:
Эта галка должна быть отключена при тестах на производительность.

Спасибо, я учту. Правда не очень пока понимаю, почему.

Аватар пользователя _аlex_ _аlex_ 19 июня 2012 в 12:18

Вот, похоже и ответ на мой вопрос:

Quote:
The answer to "How can I get the same SQL run-time?" is - you cannot. If your query reads some rows, they are cached, dependent on the storage engine in use, those rows are either in OS cache (myisam), or in buffer pool (innodb). If rows are cached, running the same query second time is much faster, because MySQL does not have to read from the disk.

Ответ на вопрос - "Как получить единое время выполнения для одного SQL запроса" - никак... Smile

Аватар пользователя natbampo natbampo 19 июня 2012 в 14:57

"_аlex_" wrote:
Правда не очень пока понимаю, почему

на рабочем сайте данная информация будет браться из кэша.
Это служебная внутренняя информация, которая если меняется - то во время разработки.

Аватар пользователя _аlex_ _аlex_ 19 июня 2012 в 16:44

natbampo wrote:
на рабочем сайте данная информация будет браться из кэша.
Это служебная внутренняя информация, которая если меняется - то во время разработки.

Ок. Век живи, век учись.

Аватар пользователя sg85 sg85 20 июня 2012 в 1:00

Вьювс всего лишь генерирует sql запрос(причем после генерации показывает этот самый запрос вместе с простеньким бенчмарком), а так же темизирует вывод результата. Т.е. по сути вы строите как раз запрос к БД, только с помощью мыши, так что вопросы по производительности скорее к вашей субд. Кроме штатных крутилок и перделок иногда полезно в тормозных представлениях использовать Вьювс АПИ, тогда можно скармливать ему практически любые запросы(за оочень редким исключением, которое даже в абстрактный слой друпала не вписывается),а так же избавляться от медленных хендлеров или плагинов, которых не так много, но бывают. Однако, постоянное написание хендлеров, плагинов, модулей под вьювс для каждого случая противоречит его изначальному назначению(избавить разработчика от необходимости написания модуля для каждого списка). Оптимизировать его не так уж сложно, хоть и труднее чем написать свой модуль, главное понять как вся эта хрень работает, по какому принципу строит запросы, и т.д. и т.п.

"_аlex_" wrote:
Ответ на вопрос - "Как получить единое время выполнения для одного SQL запроса" - никак... :)

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

Аватар пользователя _аlex_ _аlex_ 24 июня 2012 в 11:15

sg85 wrote:
Вьювс всего лишь генерирует sql запрос...

Спасибо, многое стало на свои места.

Аватар пользователя sg85 sg85 20 июня 2012 в 19:48

Мне вот только интересно, сколько у вас там по времени генерация происходит?(построение, запрос, отрисовка) А то может зря паникуете

Аватар пользователя _аlex_ _аlex_ 24 июня 2012 в 11:29

sg85 wrote:
Мне вот только интересно, сколько у вас там по времени генерация происходит?(построение, запрос, отрисовка) А то может зря паникуете

Views выводит табличное представление ноды. Выводится 200 нод на странице. Всего на данный момент нод ~300. Сама нода состоит из ~30 полей (выводятся около 10). Есть несколько привязок к терминам таксономии. Сейчас страница генерируется на моей домашней машине (mobile i7 first gen) за ~10 секунд первый раз и ~3-5 секунд после построения кеша запросов.
Самый долгий по времени запрос вызывается из функции: views_plugin_pager::execute_count_query.

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

Аватар пользователя drupby drupby 24 июня 2012 в 12:10

"inza" wrote:
Вопрос серьезный, я его пытаюсь учесть на стадии разработки сайта. Один из путей - попытаться обойтись минимальным количеством модулей, или заменить некоторые модули, не очень необходимые, чем-то своим.
Было бы интересно сравнить производительность сайта с использованием Views и CCK и без них.

Диагноз : либо дурак либо полудурок .

Аватар пользователя multpix multpix 24 июня 2012 в 16:00

"inza" wrote:
Диагноз. Урод по жизни и полный ублюдок.

ТС сорри за офтоп,
если есть интерес,
загляните в курилку, туда были перемещены практически все "технические" темы от инзы.
Даже при беглом просмотре вы поймете что это(инза),
и насколько он компетентен и адекватен.

тролля больше нет

P.S.
по вашей теме:
в вашем случае узкое место - серверная часть.

Аватар пользователя multpix multpix 24 июня 2012 в 16:01

"inza" wrote:
Намекает на выделенный сервер.

опять эта ЛОЖЬ

для вас необходимо расширено:
1. У ТС по его постам локальная среда
2. Необходима ее настройка
3. Денвер не тот инструмент

"drupby" wrote:
Диагноз : либо дурак либо полудурок .

постом выше еще одно подтверждение поставленного вами инзе диагноза.
от себя добавлю:
склочник
провокатор
дезинформатор

тролля больше нет