14 декабря 2008 в 14:22
Полтора месяца назад, после перехода на 6.х, ощутил значительный скачок в производительности системы в сторону увеличения времени генерации страниц. Доступ к странице модулей вообще начинает доводить до состояния анабиоза.
Танцы с бубном вокруг выделенного сервера не привели ни к какому сколько-нибудь значимому результату.
В состоянии здравого ума и трезвой памяти я сделал вывод о сильно разросшейся системе управления, изначально напичканой излишними модулями и кривой реализацией основных функций/модулей. В частности это касается реализации модулей Views и CCK, на которые 90% пользователей делают основной упор.
Дабы не быть голословным, привожу пример работы drupal на сервере с настройками: CPU 600Mhz, 160Mb memory, 4000Mb disk.
Вывод на главной странице 10 последних записей блога, темизированных через node-blog.tpl.php, в котором просто расписаны div и phint $node->....
данные по devel после трех перезагрузок сервера:
Page execution time was 37415.49 ms.
Page execution time was 35212.13 ms.
Page execution time was 36423.23 ms.
ЗЫ. если кто-то сможет мне объяснить, как заставить drupal работать в 30 раз быстерее - с меня пЫво (или на пЫво через WMR/WMZ)
Комментарии
хехе, еще один) у вас что-то не так с серваком либо кодом, 37415.49 ms. - это анрил.
если вы друпал непоняли то до symfony и Zend Framework... вам как до китая ползком
учите, учите симофони
а мы пока на друпале бум зарабатывать
модуль update отключить пробовали? Это первое, что замедляет загрузку страниц.
друпал я понял. я не пойму откуда такие тормоза. настройки серва я показал. на таких настройках летать должно. код не трогал.
PS. До китая, даже ползком, мне час-два потребуется с перерывами на пЫво.
у меня на главной
Page execution time was 1394.4 ms
(сейчас прям, сайт конечно не нагруженный сейчас)
так и у меня в процессе построения сайт. нереально при таких разрешениях сервера, такую производительность показывать
отключен изначально
)). А вас время загрузки вот здесь не пугает? - http://symfony.org.ua/
А вообще... за какое там время вычислительные мощности регулярно удваиваются?
Может проще подождать? ))
И кстати, от вьюс избавится вполне реально. сниппетами теми-же...
Это может происходить иногда от того что старые модули установлены, от предыдущих версий. Модули от 5 ставят на 6.
Вообще ситуация ненормальная, ИМХО. Вам просто искать узкое место надо в модулях, например. Путем поочередного отключения.
Не факт так же, что сервер по умолчанию сконфигурирован оптимально - в чистом виде без вьюс и сск и прочих моделй как друпал себя чувствует на вашем сервере?
как-то невяжется
Я увеличивал время выполнения файлов и размер доступной памяти...
Ну и хостера перед этим менял...
Я так понял по показаным параметрам у вас вдс, если коротко то на даных параметрах - 160mb RAM запустить что то кроме статики не особо и получится, реальный минимум для ВДСа - 256, на этом еще как то запустится можно.
Вообщем пишите в ICQ или через форму контакт, что реально с делать с оптимизацией вдс - сделаем,
ICQ в профиле.
ну, можно и час разрешить. это выход? скрипты в разы быстрее должны выполняться. а 160 мозгов мало для их выполнения?
вы издеваетесь? для каждого проекта отдельный вдс? данунах
сниппетами?
ничего не напутали?
>сниппетами?
>ничего не напутали?
Почему же напутал... смотрите сколько полезных и хороших выводов сниппетами делается:
http://setegnom.com/drupal/snippets
Если Вы вьюс для вывода инфы используете... вполне можно заменить.
Скорость по моим ощущениям меняется в разы.
ну, я забыл уточнить
у меня 1,7 проц
и 1,5 гига оперативки
вдс-улёт?
Для начала включаем eaccelerator. Без него тяжко. Реально тяжко.
Во-2, включаем mysql query cache. Если у вас действительно вдс-улёт, то там изначально в mysql нет кэширования.
Ах да, ещё список включенных модулей покажите.
да
-------------------------
Administration Menu
--CCK
Content, Email, FileField, ImageField, Link, Number, Option Widgets,Text, User Reference
--Core
Blog, Blog API, Book, Comment, Contact, Content translation, Locale, Menu, Path, PHP filter, Poll, Profile, Search, Syslog, Taxonomy, Trigger, Upload
--Date/Time
Date, Date API, Date Timezone
--Development
Devel, Devel node access, Theme developer
--ImageCache
ImageAPI, ImageAPI GD2, ImageCache, ImageCache UI
--Javascript tools
Lightbox2
--Messaging
Messaging, Simple Mail
--Notofications
Content Notifications, Notifications, Notifications Lite, Notifications UI
--Organic groups
OG Alias, Organic groups, Organic groups access control, Organic groups actions, Organic Groups Notifications, Organic groups Views integration
--Spam control
CAPTCHA, hidden_captcha, Text CAPTCHA
--Таксономия
Tagadelic
--User Interface
jQuery Update
--Views
Views, Views UI
--Voting
Voting API
--Другой
Flag, Flag actions, Pathauto, Poormanscron, Token
А базу проверял? Может какая таблица повреждена...
два друпала установлены параллельно. симптомы одинаковы
1. Купи нормальный хостинг - Дома селерон 2500 в 4 раза медленнее чем хостинг Руцентр тариф 300
2. Поставь APC и выдели ему 30-60 мегабайт
3. Оптимизируй базу модуль db_maintenance
4. Конечно же включи кэш mysql
Poormanscron - а оно вам надо крон таким образом запускать?! Это ж тоже нагрузку создает именно на сайт. Лучше все же через lynx или wget cron.php гонять, ИМХО, у вас же сервер свой.
beerman,
1) это только включенные модули? хмм. отключите Devel node access и Theme developer. Последний особенно тяжелый. Коль вы привели в пример главную, то девелом померьте количество запросов и время на них. Если не трудно - можете и тхт-файлом список всех запросов прикрепить.
2) ну и
Что у вас с этим?
так к слову к советам с кешами аля APC, eaccelerator, mysql table cache и тому подобное.
Все выше перечисленые методы требуют памяти, оперативной памяти и побольше.
В указаных параметрах ВДСа указано что всего 160mb.
и в эти 160mb надо чтоб влез mysql, apache,ssh часть других сервисов что есть... а если прибавить системы кеширования, получим критическую нехватку памяти.
выводы?
В данном случае, на 160 мегах, удивительно не то, что оно тормозит, а то, что вообще работает... Или 160 мег -- это не скрипт? Если нет -- увеличивайте.
160 памяти сервера это полный сакс. Только себя мучать, даже mysql не закешировать как следует.
У меня на один запрос страницы нужно ~50мб для php плюс кеш mysql, и что три подряд запроса (форкнутые php висят в памяти) и все.
Вобщем при таком сервере нада nginx + fast-cgi (без апача) с 2-3 форками php и остальное "забить" кешем mysql(не заежая на swap), при этом имейте ввиду что выделение и использование памяти зависит от системы виртуализации(в большинстве случаев 4:1, то есть при нормальном раскладе при выделении для php 48мБ у вас будет занято ~12 хотя сервер покажет >48)
пресловутый экстремум -- "drupal гавно"?
раз в сутки ночью нагрузку не создает.
eAccelerator включил. результат:
Memory used at: devel_init()=0.33 MB, devel_shutdown()=11.9 MB.
вместо
Memory used at: devel_init()=1.68 MB, devel_shutdown()=28.2 MB.
mysql cache query включен
query_cache_type=1
query_cache_size=5M
я этого не говорил.
Время генерации страницы насколько уменьшилось?
Верно, на улёте я тоже докупал памяти, до 256 метров. Но это я ставил nginx и полностью отключал апач.
в среднем до 5-10 секунд
Ок. Увеличение ОЗУ и размеров кэша мускула и кэша eAcceleratora позволит еще несколько ускорить загрузку. Теперь можно посмотреть и на лог запросов к БД из Develа
Executed 247 queries in 1142.66 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 5824.8 ms.
Ну вот, в принципе, на этом наверное, всё, на вдс-улёте без увеличения памяти, и без перехода на nginx быстрее не станет.
Что то вы меня запугали, у меня на простом виртуальнике 3 сайта на wordpress летает (на каждом ~50-100 посетителей в сутки). Для drupal выделенный по вашему обязательно как минимум :(, это какие параметры у хостинга должны быть, чтобы те же три сайта на drupal работали ?
3 сайта по 50-100 уников... да любой шаред потянет конечно! но eaccelerator лучше включить. )
Спасибо, Владимир успокоили. Но где тогда та грань, когда drupal виртуального аккаунта на хостинге не хватит и придётся задумываться о VPS и VDS. Для примера могу сказать, что при прямых руках и нормальном хостинге, wordpress можно дотянуть до 4000, и это та грань на которой уже начнётся поиск VPS хостинга, можно и больше но это уже из разряда хождение по лезвию. Но опять же это достигается с помощью различных плагинов созданными энтузиастами и включает в себя отключение проверки обновлений, настройкой нормального кеша и другим незначительным тюнингом. Если брать, чистый wordpress без напильника, то этот порог начинается с 1000 посетителей.
Если на сайте не требуется регистрировать пользователей, то и не возникнет никаких проблем. Ваши 50-100 человек - это гости или зарегенные пользователи?
beerman : Как была решена проблема?
batbug, вопрос разъяснил Владимир, но вы меня заинтриговали, что при регистрации появятся проблемы. Отвечаю на ваш вопрос, простые комментарии ни чего больше. Но всё таки хотелось бы получить информацию на предыдущий мой вопрос по поводу грани виртуального и VPS у drupal подобного материала пока не могу найти только информацию, что максимум drupal может выдержать 50 000 но это точно не виртуальный аккаунт
Чем больше на сайте ходит залогиненных пользователей, тем хуже будет сайту.
Обычно говорят, что 500 посетителей в день = переход на ВПС.
Еще говорят, что переход на ВПС - это когда в час около 10 зарегенных ходит.
У меня сейчас больше чем 500, но пока шаред выдерживает, только пришлось попросить увеличить пхп_мемори_лимит.
И еще - говорят, что лучше заплатить за ВИП-шаред, чем за небольшие ВПС, особенно если не умеешь их настраивать.
+1.
Думается мне, сменой cms
Куда менять-то? есть что-то лучшее,кроме как писать под задачу?
Здесь был какой-то разговор про "задачу" и "писать" ?