Низкая производительность

Главные вкладки

Аватар пользователя Гость Гость (не проверено) 20 мая 2006 в 16:54

Приветсвую всех.

Собственно у меня ситуация следующая: низкая производительность, точнее, высокое время генерации страницы (2,5+ сек) меня гнетёт.

Само собой, на это время влияют очень многие факторы, но в данном случае причина скорее всего (хостер подсказал) в больших запросах памяти в процессе построения страницы (у него своп часто вкючается и ему приходится самый толстый процесс mysql-я грохать). Каждому процессу mysql выделяется по 20 и более (до 40 было) метров памяти, каждому Апачу 10-15. В случае с Апачем - я так понял, что это нормально, то вот с MySQL-ем - это нормально? Самое неприятное, что процесс mysql, который держит эту память - отпускает её не сразу (что влияет на это - я пока не нашёл).

И ладно бы всё списать на настройки со стороны сервера, но как быть вот с такими данными (модуль devel): в процессе генерации сраницы - 300-400 запросов к БД (!), причем время, затрачиваемое на сами SQL-запросы - это приблизительно 25-30% от общего времени генерации страницы (но тут мне как-то не верится; корректны ли показатели devel.module? Вроде ж принято считать, что работа с БД - это основной тормоз сайта...).

Ещё одна не очень понятная мне вещь (опять же - хостер натолкнул): в модуле image для вывода "случайной картинки" (а это на каждой странице, в блоке) используется SQL конструкция вида: "SELECT ... ORDER BY RAND()". Почитал немного на эту тему и понял - что это действительно может вызывать проблемы (на больших таблицах). Сам факт того, что большое кол-во SQL-запросов на страницу + такой подход = мой вывод, что скорее всего расход памяти (и тормозтутость как следствие) есть результат не очень качественного кода (модулей или движка - не знаю пока).

Установлено порядка 38 модулей, кэширование для анонимных посетителей - включено (у них, в принципе, порядок - не сильно медленно работает, проблемы - у залогиневшихся пользователей), у MySQL выключен кэш запросов (query_cache_size = 0, название параметра - по памяти писал). Что ещё? Посещаемость не высока: порядка 60-80 уник. посетителей и около 500-700 просмотров в сутки. Ах да! Дрюпал версии 4.6.6.

Народ, если у кого какие мысли возникнут как с этим бороться, не поленитесь высказать их тут - я буду вам весьма признателен. Единственное "НО": переход на 4.7 - не надо предлагать и советы типа "ДОбавить памяти на сервер", тоже к сожалению - в данной ситуации
особого мысла не имеют - не прокатит это (я пробовал :-/). И сменить хостера - тоже не выход (не я это решаю). Интересно победить это именно своими силами.

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

Лучший ответ

Аватар пользователя Basilienis Basilienis (не проверено) 19 июня 2006 в 19:01

38 модулей - это жесть! Smile
Включение кэша mysql и прочая тонкая настройка mysql лично мне дали процентов 30 ускорения.
Часто на хостингах узким местом является производительность дисковой подсистемы. Если есть возможность посмотреть top через shell, то это сразу видно: если памяти хватает и нагрузка на процессор маленькая, то скорее всего это оно.

Комментарии

Аватар пользователя Гость Гость (не проверено) 20 мая 2006 в 23:27

Drupal вообще-то лучше устанавливать на отдельный комп, если конечно, хочется использовать порядка 38-ми модулей, иначе будут тормоза. В идеале, лучше использовать два-три модуля, если ставишь Drupal у хостера. Более того, так как код модулей из contrib пишут энтузиасты, хорошо, что он вообще работает. Говорить о минимизации запросов к памяти не приходится. Каждый решает свои проблемы как умеет и разработчики модулей - не исключение.

Сам я, когда исследовал Drupal пришёл к выводу, что самый лучший хостер для него (если не устанавливать на отдельный комп) - это Servage. Так как изначально он используется порноиндустрией и поэтому там повышены производительность, в результате чего использовать Drupal становится возможным. Все же остальные просто не дотягивают до их уровня по мощностям. В результате хостеры говорят о больших запросах скрипта.

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

Аватар пользователя axel axel 24 мая 2006 в 10:42

По моему опыту, для сайтов с посещаемостью до 1000 уникальных хостов в день Drupal вполне можно ставить на виртуальных хостингах с тарифами в районе 10$. Инфобокс, Мастерхост, Агава - время от времени бывают тормоза, но в общем и целом приемлемо. Если только не перегружать сайт разными модулями, особенно из contrib, которые как правильно отмечено могут иметь очень низкое качество кода. Модули в составе движка проходят контроль качества, но за доп. модулями такого контроля нет.

--
Axel,
Darcs-репозиторий разработок для Drupal

Аватар пользователя Basilienis Basilienis (не проверено) 19 июня 2006 в 19:01

38 модулей - это жесть! Smile
Включение кэша mysql и прочая тонкая настройка mysql лично мне дали процентов 30 ускорения.
Часто на хостингах узким местом является производительность дисковой подсистемы. Если есть возможность посмотреть top через shell, то это сразу видно: если памяти хватает и нагрузка на процессор маленькая, то скорее всего это оно.

Аватар пользователя rgb rgb 21 июня 2006 в 10:49

"Basilienis" wrote:
Включение кэша mysql и прочая тонкая настройка mysql лично мне дали процентов 30 ускорения.

Да - я проводил небольшое исследование этого вопроса, и получил некоторый прирост. Но, к сожалению, в моем случае это не прокатило: хостер не внял просьбам. (Не надо только советовать поменять его! Это не обсуждается ;-))

"Basilienis" wrote:
Часто на хостингах узким местом является производительность дисковой подсистемы. Если есть возможность посмотреть top через shell, то это сразу видно: если памяти хватает и нагрузка на процессор маленькая, то скорее всего это оно.

Да - топ смотрел. Он показывает, что процессы мои слишком "жирные", много памяти потребляют и её часто не хватает. Такое впечатление, что после отработки запроса кто-то не дает MySQL-ю освобождать занятые ресурсы (память),и какое-то время этот "жирный" MySQL-процесс висит в памяти. Возможно, что это следствие каких-то настроек MySQL-я или PHP, а может ещё чего... У себя я повторить это поведение не смог (правда, могло повлиять и то, что у меня Винда, а не BSD-сервер).