24 июля 2007 в 0:50
Господа, я недавно поставил себе Друпал, потому что был наслышан о нем как о весьма достойной системе (раньше пользовал Joomla),
И вот, я поствиль его, все по началу работало прекрасно, а потом я стал замечать, что сайт стал немногожечко, периодически подтормаживать
Не так чтобы критично, но периодически появлялись задержки до 10 сек, нуи общее время отклика немного упало (где-то 2-3 по замерам fasterfox). Конечно, это н еочень приятно, но терпимо.
Прочитав про модуль вevel я решил также его опробовать и был крайне неприятно удивлен, узнав, что главная страница у меня дает 170-200 (!) запросов к базе.
Время герерации, однако, выдается небольшой, но это как-то плохо соотносится с задержками.
Хотелось бы спросить у других пользователей, сколько дает запросов гл страница у них и сколько вообще считатеся нормой?
Грешу, конечно, на модули, хотя и старался не увлекаться установкой всего подряд
В частности из работающих у меня :
Comment
Menu
Profile
Upload
Throttle
Authorship
BBCode
Community Tags
XML Sitemap
Meta tags
Quicktags
Smfforum
Taxonomy Menu
Paging
Tagadelic
Из-за того, что у меня очень много запросов taxonomy_get_vocabularies грешил на Taxonomy Menu, но его отключение не дало ничего.
В общем...как-то странно это усе.
Знакомые намекают на хостера, но тем не менее.
Комментарии
модуль devel - через него можно многое увидеть. На запросов и правда масса, так что удивляться не стоит....
Обратите внимание на тему и theming, при переходе с табличной верстке на DIV вывод контента ускоряется в ~1.5 - 2 раза, броузеры и web сервера сейчас оптимизируют именно под DIV !
По поводу DIV не DIV: броузеры , а тем более серверы ни кто не оптимизирует :-).
Просто при построении DOM структуры документа броузер, по любому, должен получить все контейнеры и их свойства.
В случае с CSS свойства уже лежат готовые в одном(2,3...) файле(к тому же часто на клиенте закешированы) и броузеру остаётся только все расположить.
А таблицу нужно ещё всю вычитать перед началом построения ну и плюс огромное количество кода, в котором после 4-5 вложений разобраться без пол литра низзя уже...
Советую почитать презентацию по теме :).
В форуме уже обсуждались вопросы связанные с большим количество запросов. Основные генераторы запросов - модуль локализации и path. Вообщем для друпала такое количество - норма.
> А таблицу нужно ещё всю вычитать перед началом построения
IE действительно читает всю таблицу, и только потом рисует. FireFox рисует по мере подгрузки ячеек.
To PVasili
смотря что называть оптимизацией
Факты :
1) Сокращение объема станиц для загрузки;
2) Кеширование css со стороны сервера, а значит и более быстрый доступ к нему.
Расскажите, пожалуйста, как конкретно оптимизируют СЕРВЕРА?
А вообще модулю Devel можно верить? А то данные, выдаваемые им, меня малость смущают - на локалхосте:
Page execution time was 2986.42 ms. Executed 300 queries in 1029.77 milliseconds.
конкретно сервера не оптимизируют - просто добавляют nginx и все.
Вопрос - есть один сайт - там применен smarty шаблон-кеш движек - работает - просто летает, так как почти все отдается статикой.
Соответственно вопрос - друпал когда-то тоже умел работать с smarty - может кто-то пробовал?
smarty - http://drupal.org/project/smarty и тема для него - http://drupal.org/project/garland-smarty
неужели никто не сравнивал ускорение с использованием smarty? поробовал - вроде работает, а оно должно кешировать вообще все - и для анонимных и для зарегистрированных?
Smarty - абсолютно ненужный шаблонизатор. Кэширует он в PHP-код, а вовсе не в статику. Заметного ускорения не получите. Интересные варианты могут быть получены только с использованием серверных решений: nginx, light httpd, memcached и все такое прочее.
> Smarty - абсолютно ненужный шаблонизатор. Кэширует он
да, он кеширует и поэтому сайты летают даже быстрее друпаловских
nginx как прокси поставил, но это не кеш, он для другого
light httpd это вэб сервер, зачем он?
memcached - под него надо код переделывать - я так понимаю
поставил еще eaccelerator - вот с ним полегчало, но иногда он сбоил - то есть выдавал старые результаты, но это на фре рогатой, под линуксом вроде не жаловались.
интересно - что есть наподобие eaccelerator? или что еще сделать для усиления вэб сервера?
>kiev1 says:
>да, он кеширует и поэтому сайты летают даже быстрее друпаловских
Первый сайт у Вас ведь не на Drupal? Чего ж тогда их сравнивать?
Если б один был на Drupal + Smarty, а второй Drupal - Smarty, тогда да. Мои рукописные сайты тоже летают. Вопрос в том, как заставить Drupal летать с сохранением всех модулей и функциональности.
"наподобие eaccelerator" есть APC Но в случае использования Друпала eAccelerator работает немного быстрее.
Из активных проектов Xcache ещё.
Подскажите плиз, как вывести на страницу время генерации, так называемое JUST TIME а то перепробывал много спосоьов и всё напрастно?
зарание благодарен!
вообще-то nginx - это полноценный http-сервер, причем выдает он статику с сумасшедшей скоростью, однако в случае с друпалом от него толку мало
>igdrasil@drupal.org says:
>вообще-то nginx - это полноценный http-сервер, причем выдает он статику с сумасшедшей скоростью,
>однако в случае с друпалом от него толку мало
Почему? Поясните, пожалуйста!
Я с Друпалом только несколько дней знаком, но собирался его как-то завязать с nginx-ом. Пока с Друпаловским кэшированием не разбирался, но вроде бы он может кэшировать страницы поблочно, а в nginx есть неплохой механизм ssi для сборки сайтов из статики и динамики.
Или Вы про то, что руками много ковырять придется? В конечном итоге ведь можно получить собранную html из страницы и класть ее в кэш, отдавая потом nginx'ом. И перекэшировать страницу при ее изменении. Ведь так?
>однако в случае с друпалом от него толку мало
Вовсе нет... Для отдачи статики в таком случае не будут стартовать тяжелые процессы Apache.
Дело не только в статике. У nginx и lighttpd другая архитектура и они потребляют меньше памяти в сравнении с Apache. И через fastcgi PHP будет работать не медленнее чем под mod_php. К слову drupal.ru после решения больного вопроса с сервером переедет на nginx. Просто любопытно посмотреть как будет вести себя друпал на нём
Я использовал nginx именно для этой цели - разгрузить память от процессов Apache... В итоге Друпал чувствует себя очень даже хорошо.
>>Вовсе нет... Для отдачи статики в таком случае не будут стартовать тяжелые процессы Apache.
а много там статики? стили, скрипты, немного графики, все прекрасно живет в кеше браузера и запрашивается 1 раз. единственный вариант - это фотогалерея или просто очень богатый графикой портал
спасибо, странно - APC нет в репозитарии дебиана, в редхете есть php-pecl-apc
в Debian 4.0 есть Xcache
Подскажите плиз, как вывести время генерации в Drupal не только для администратора как это делает devel, а то перепробывал много способов и всё напрастно?
зарание благодарен! А то не кто и не ответил
nginx наверно надо ставить как прокси, а иначе чем он от апача будет отличаться? или один как сервер, второй как прокси?
nginx будет выполнять роль реверсного прокси. Также в этом случае применяют другую терминологию: nginx - фронтенд, Apache - бэкенд.
А кто каким образом запускает PHP как fastcgi?
Раньше я от Apache совсем отказался. Была у меня связка nginx + spawn_fcgi из lighttpd + PHP. Но последние два пункта работали крайне нестабильно и частенько nginx терял с ними связь. Выдавалось сообщение "Gateway timeout". Вылетало не часто, но когда работало, то работало очень быстро.
Потом меня эта нестабильность замучала, я поставил backend'ом Apache. Но до сих пор мучают мысли о поиске стабильного FastCGI решения для PHP. Сам PHP, по идее, работает в режиме FastCGI, но где-то читал, что обработав несколько тыс. запросов он вылетает. Сам не экспериментировал.
Может кто-нибудь уже знает "ресепт"?