16 сентября 2012 в 14:08
Перенес сайт на VPS (CentOS + Apache + Nginx + eAccelerator). Проблема в том, что меня не устраивает скорость отдачи страниц после простоя т.е. когда на них долго не заходишь.
Заходим на определенную страницу (каталога с кучей товаров) после простоя: время генерации около 5000 мс.
Тут же обновляю страницу: 2500 мс
Обновляю еще раз: 2000 мс
Проходит 1-2 минуты простоя и опять время генерации страницы возрастает до 5000 мс.
С чем это связанно? Куда копать?
Я думал на конфиг eAccelerator, может быть там увеличить время хранения кэша, хотя хз...
Комментарии
5000 мс- это много, посмотрите firebag'ом какой скрипт дольше всего грузиться, там и копайте. Почитайте здесь
Я про серверную сторону имел в виду. Скрипты и графика на сайте в норме, тормоза именно на серваке.
так скрипты и обрабатываются на серваке, статью посмотрели?
1. установите модуль девел и включите статистику по мускулу и времени генерации и расхода памяти
2. Если проблема в хостере меняйте хостера
3. если проблема в сайте, ищите кто у вас грузит. что 2 секунды, что 5 секунд это очень много для сайта
Как вообще меряли загрузку страницы, каким инструментом?
devel на большой каталожной странице показывает следующее:
Executed 7731 queries in 4975.9 milliseconds.
Page execution time was 9243.45 ms.
271.72ms node_load
255.16ms cache_set
240.37ms cache_set
238.81ms cache_set
222.76ms cache_set
145.77ms cache_set
145.72ms cache_set
121.97ms cache_set
86.23ms node_load
52.07ms taxonomy_node_get_terms
29.39ms taxonomy_node_get_terms
.... ну и так далее
Включит в настройках производительности кэш (нормальный рекомендуемый режим) на 24 часа. Запросы на cache_set исчезли.
Теперь выводит следующее:
31.59 taxonomy_node_get_terms
24.3 taxonomy_node_get_terms
14.39 execute
5.77 pre_render
и дальше куча мелких запросов типа taxonomy_node_get_terms
Походу, проблема была именно в настройке собственного кэша друпала: admin/settings/performance
Скорость генерации страницы стала более постоянной от 2,5 до 3 секунд.
Что делать, что бы еще ускорить загрузку?
Выложить код генерирующий каталожную страницу, ну чисто поржать.
Потом съезжать с этого VPS, несмотря на то, что оплатили на год вперёд
Печальный случай. Столько запросов не должно быть. Ищите косяки в коде.
вам нужно искать откуда взялись эти самые 7700+ запросов в мускул.
Должно быть 300-500, если 700 это уже "не хорошо" ну а в 10 раз больше, сами понимаете
Если у вас Уберкарт старый. то нужно обновить и всякие модули проверить на обновления
А сайтик то не простой. Есть парочка страниц каталога, где выводится более 200 товаров сразу на страницу без пэйджера. Это может быть причиной, верно ведь?
з.ы. уже консультировался по проблеме такого изъ***а без пейджера, увы увы увы я не могу его туда поставить из-за тупости предыдущего разработчика, который сделал так, что на этих гигантских страницах завязано SEO. Боюсь, что в случае установки пэйджера яндекс переранжирует и релеватной может стать другая страница, которую он разумеется оценит менее релевантно и позиции пойдут вниииииииииз...
200 товаров не так и много если их правильно приготовить.
Сейчас вам нужно первым делом решить проблему с 7700+ запросами и довести это хотя бы до 700-800 как максимальное значение.
А потом уже думать о кеше.
Я более чем уверен что ваши модули хакнуты и поэтому вы их не обновляете, но это очень серьезная проблема:
1. Обновления модулей это повышения быстродействия
2. Обновление модулей это повышение безопасности
Нарпимер убунта 2.4 версии загружает атрибуты поштучно. то есть имеете 200 атрибутов и получаете 200 запросов в мускул. Если вы имеете старую версию нодевордс, то он в нескольких местах имеет загрузку ноды в таком варианте
node_load(array('nid' => $nid));
А если при ноде_лоад указывать массив. то данные берутся не из кеша, а опять идет hook_nodeapi() на загрузку ноды и так 2-3 раза. каждый раз получая по 200 атрибутов. то есть 600 запросов на товар
Не, кстати модули не хакал. Ну если честно, то один хакал, точнее патчил т.к. модуль редкий и разработчик на него забил, а многим он был нужен, народ сам придумал как исправить там кое-какие косяки. Пожалуй, обновлю все, что можно, посмотрю что будет...
Обновил модули, коих кстати оказалось немного для обновления. Разве что не получилось обновить Ctools и Imagecache из-за ошибок несовместимости Drupal 6.26 + PHP 5.3 + эти модули.
В итоге на той же каталожной странице я получил следующее:
Executed 3916 queries in 729.4 milliseconds.
Уже лучше, но скорость генерации данной страницы осталась прежней
Нашел "штучку-дрючку", которая прибавляла к времени генерации страницы почти целую секунду:
это скрин фрагмента настройки поля ubercart_price (Цена продажи) в VIEWS (работа с полями).
Если стоит как "Ubercart price", то работает медленнее, чем "Числовая".
кстати, после изменения формата вывода цены ubercart, devel стал показывать:
Executed 1104 queries in 178.62 milliseconds.
И все же, после простоя время генерации может составлять больше 5 сек.
Делаю рефреш - генерится в два раза быстрее...
Что ж за....???
Еще смотрите где у вас много дублирующихся запросов 20+ на одну функцию.
Такие запросы как node_acess и другие.
Иногда помогает отключение во views проверок на доступ.
А где это отключить в Views? Первый раз слышу
Дополнительно -> настройки запроса -> Выключить перезапись (rewriting) SQL
А, понял, это в семерке наверное есть, у меня drupal 6 стоит.
и в 6 есть:
Расширенные настройки:
Query settings: Disable SQL rewriting
Но если у вас есть хуки на перезапись запросов, то этого делать не стоит.
да, это в Views 3 есть, у меня 2.16 пока стоит, попробую вечером установить тройку..
Попробовал Views 3. Пока не стал оставлять т.к. обновление покоцало мне все настройки вьюх.