19 июня 2012 в 0:06
Хочу заняться оптимизацией одного из сайтов, который начал изрядно подтормаживать и буквально сразу столкнулся с проблемой.
От чего зависит скорость генерации страницы, а конкретно скорость выполнения запросов mySQL? Выключил в движке и на сервере все возможные оптимизации, но не могу понять, почему первая загрузка страницы происходит долго, а последующие загрузки той же страницы - в несколько раз быстрее. Включил вывод запросов в devel. Количество запросов везде одинаковое. Но скорость исполнения каждого запроса при первой загрузке и при последующих сильно отличаются. Меня же как-раз не устраивает скорость исполнения первого запроса, и хочется иметь возможность производить замеры без постоянной перезагрузки сервера (после перезагрузки сервера - загрузка страницы происходит также долго, как в первый раз).
Комментарии
Да, сервер на апаче - denwer (в конфигурации по-умолчанию произведены незначительные в рамках данного вопроса изменения). MySQL - 5.1.4
Включено около 30 дополнительных модулей. Из тяжелых активно используется fields и views. К объему памяти на генерацию страниц притензий пока нет. Кеширующих модулей нет. Во вьюс кеши выключены, в модуле devel выставлена опция для чистки кешей для каждой страницы.
Не думаю, что проблема в количестве модулей, либо в конкретном модуле.
Просто общая информация
Есть понятие время выполнения запросов к бд(обычно самое долгое, зависит от сложности БД, её объема и сложности запросов) и время отрисовки страницы, зависящее от кода PHP(самое тормозное в нем регулярные выражения, кучи циклов и т.д., если сами там велосипедов не изобретали, то обычно время минимальное), во вьювс, к примеру, это показано наглядно, и у меня как-то общее время генерации вьюхи достигало 90 секунд(т.е. вылет по таймауту), кое-какими манипуляциями над запросом(через апи вьювса) было уменьшено до 0.1 секунды без кэширования)
в 1й раз у Вас страница отрисовывается без кеширования, 2й раз идет из кеша
так же не забывайте что SQL запросы так же кешируются самой СУБД.
Видимо потому что при этом чистится кэш
Я так понимаю человеку, важно получить прирост производительности в секунднах, а не в наносекундах
Собственно вьюсом страница и генерируется. Подскажите пожалуйста, куда копать для оптимизации запросов во вьюс. Пока информации по этому вопросу у меня крайне мало (понятно что оптимизировать надо, но не понятно как).
Да, на данном этапе я и хочу отключить кеши. Кеши друпала чистятся при каждой загрузке принудительно, вероятно дело в кешах сервера. Пробежал конфиги апача, php, mysql, все явные упоминания о кешировании и оптимизации выключил. Для mySQL обнулил и запретил все нагугленные опции кеширования. Если интересно - прикреплю конфиги.
И что же такое в Вашем понимании "тяжелые" модули?) Views? да... админка там тяжелая, но простых юзеров в неё не пускают обычно, сами представления медленнее чем свои модули, разница как раз в наносекундах. Какой нибудь уберкарт? там тяжесть скорее из-за кучи лишьнего хлама, которая просто никогда не будет использоваться на сайте, Devel? ага, тяжелый, однако кроме админа обычно его никто и не видит + на работающем сайте он отключен.
что это опция такая? Эта - "Rebuild the theme registry on every page load "?
Да. Думаю, кроме кеша форм и тем (обе чистятся по данной опции), в моей сборке других кешей нет (кеш вьюсов отключен, специальных модулей кеширования не установлено). Может быть остается кеш меню и что-то еще на уровне ядра, но меня это не сильно волнует, поскольку количество запросов по данным devel не отличается при первой и последующих загрузках.
Эта галка должна быть отключена при тестах на производительность.
Спасибо, я учту. Правда не очень пока понимаю, почему.
Вот, похоже и ответ на мой вопрос:
Ответ на вопрос - "Как получить единое время выполнения для одного SQL запроса" - никак...
на рабочем сайте данная информация будет браться из кэша.
Это служебная внутренняя информация, которая если меняется - то во время разработки.
Ок. Век живи, век учись.
Вьювс всего лишь генерирует sql запрос(причем после генерации показывает этот самый запрос вместе с простеньким бенчмарком), а так же темизирует вывод результата. Т.е. по сути вы строите как раз запрос к БД, только с помощью мыши, так что вопросы по производительности скорее к вашей субд. Кроме штатных крутилок и перделок иногда полезно в тормозных представлениях использовать Вьювс АПИ, тогда можно скармливать ему практически любые запросы(за оочень редким исключением, которое даже в абстрактный слой друпала не вписывается),а так же избавляться от медленных хендлеров или плагинов, которых не так много, но бывают. Однако, постоянное написание хендлеров, плагинов, модулей под вьювс для каждого случая противоречит его изначальному назначению(избавить разработчика от необходимости написания модуля для каждого списка). Оптимизировать его не так уж сложно, хоть и труднее чем написать свой модуль, главное понять как вся эта хрень работает, по какому принципу строит запросы, и т.д. и т.п.
В логах вьювса как раз это самое время и пишется, ибо запрос по сути там всего 1, правда некоторые хендлеры добавляют свои мелкие запросы, время обработки которых попадает уже во "время отрисовки представления", однако всех их видит девел(правда из за того что их там набирается до...., отследить их довольно сложно)
Спасибо, многое стало на свои места.
Мне вот только интересно, сколько у вас там по времени генерация происходит?(построение, запрос, отрисовка) А то может зря паникуете
Views выводит табличное представление ноды. Выводится 200 нод на странице. Всего на данный момент нод ~300. Сама нода состоит из ~30 полей (выводятся около 10). Есть несколько привязок к терминам таксономии. Сейчас страница генерируется на моей домашней машине (mobile i7 first gen) за ~10 секунд первый раз и ~3-5 секунд после построения кеша запросов.
Самый долгий по времени запрос вызывается из функции: views_plugin_pager::execute_count_query.
В принципе - на данный момент время генерации страницы терпимо, но я боюсь увеличения времени генерации с расширением системы (увеличении количества нод, терминов в связаных словарях). Ибо уже на грани.
Диагноз : либо дурак либо полудурок .
ТС сорри за офтоп,если есть интерес,
загляните в курилку, туда были перемещены практически все "технические" темы от инзы.
Даже при беглом просмотре вы поймете что это(инза),
и насколько он компетентен и адекватен.
тролля больше нет
P.S.
по вашей теме:
в вашем случае узкое место - серверная часть.
опять эта ЛОЖЬ
для вас необходимо расширено:1. У ТС по его постам локальная среда
2. Необходима ее настройка
3. Денвер не тот инструмент
постом выше еще одно подтверждение поставленного вами инзе диагноза.от себя добавлю:
склочник
провокатор
дезинформатор
тролля больше нет