Infanty 13 июл 2009 в 05:02

Оптимизация Drupal

17 мин

30K

Drupal*

+56

Комментарии 69

НЛО прилетело и опубликовало эту надпись здесь

Valeratal 13 июл 2009 в 07:34

Спасибо за статью
однако, Пример такого ненужного модуля – Statistics. Вместо статистики выдаваемой данным модулем, можно использовать статистику сервиса — Google Analytics.

а количество просмотров данной ноды ГА тоже может выдать пользователю?

ppa80 13 июл 2009 в 10:15

Может

Valeratal 13 июл 2009 в 10:32

расскажите как?
выдать именно пользователю, а не человеку с доступом в ГА :)
p.s. Заодно вывод наиболее популярных материалов в разбивке по типу (например, полуярные записи в блогах, популярные темы форума и тд)

ppa80 13 июл 2009 в 10:49

Простите, не сконцентрировал внимание на «выдать пользователю» :)
Но в любом случае, в GA можно дать доступ пользователю ко всем отчётам через Диспечер пользователей. Не исключаю, что через API это тоже можно сделать.

sfghelios 13 июл 2009 в 12:46

Google Analytics Tracking API:

var pageTracker = _gat._getTracker(«UA-12345-1»);
pageTracker._trackPageview("/home/landingPage");

Ну а дальше — дело техники (создать модуль и реализовать что душе угодно)

Infanty 28 июл 2009 в 09:23

Многим хватает отображения количества посещений за сутки, с этим прекрасно справляется Google Analytics (при условии очень медленного сервера).

Valeratal 28 июл 2009 в 12:58

Ну, тогда уж счетчик livinternet ставить
хотя конечно дело вкуса

odessky 13 июл 2009 в 10:26

Если что — я продаю VDS оптимизированные под Drupal. nginx+php-fpm+memcache. Сайты просто летают. А апач выкинут ибо ненужен.
Пишите в хабрапочту

GogA 14 июл 2009 в 20:45

Одесский, сколько на одном вдс оперативной?

odessky 16 июл 2009 в 06:17

От 256mb до 2G :)

krig 13 июл 2009 в 12:38

Странно что автор не упомянл о смене движка кэширования с БД на memcache — даже если опустить все остальные виды оптимизации со стороны сервера, замена хранилища кэша на мэмкэш сразу же дает идимы приросто производительности при второй и последующих загрузках страниц (элментов страниц).

sfghelios 13 июл 2009 в 13:23

Это и так все знают… Интересна первая часть, где рассказывается именно о настройках Друпала. Оптимизация сервера — это не только для него, но и для других CMS тоже подойдет.

Infanty 13 июл 2009 в 19:02

В Authcache можно использовать движок memcache или как в примере — всё хранить в БД.

Alinaki 13 июл 2009 в 13:44

Про Cacherouter забыли — а ведь если на сервере хорошая дисковая подсистема, можно перевести кеш из базы на файлы. Я уж молчу о разделении кешей.

Infanty 13 июл 2009 в 19:03

2. Если необходимо кэшировать страницы только для анонимных пользователей (без аутентифицированных), можно установить модуль Cache Router — пропустили по тексту наверное.

Alinaki 14 июл 2009 в 01:44

И у аутентифицированных есть чего кешировать. А вот как раз насчет Authcache я сильно сомневаюсь. Визуально — да, будет быстрее. А подгружать информацию для самого пользователя и прочее — сколько еще запросов к базе надо совершить?

Infanty 14 июл 2009 в 19:59

Authcache — он как раз и кэширует инфу у каждого зарегистрированного пользователя.

Alinaki 15 июл 2009 в 12:30

Он АЯКСом подгружает измененное. Ускорение чисто визуальное, серверу только хуже. Лично я предпочитаю вторгаться в структуру БД при помощи hook_schema_alter для некоторых запросов. Для числа новых комментариев, например. В друпале есть чего ускорять, но точно не при помощи Authcache.

Infanty 28 июл 2009 в 09:28

Ускорение практическое, а не визуальное, тестирование Вам всё покажет. Вторгаться в структуру БД и в ядро Drupal — это строить не портируемое решение, проще сразу на C++ всё написать.

SkyCat 13 июл 2009 в 17:48

>К сожалению не все модули Drupal версии 5 реализованы для Drupal версии 6 (например, модуль Sphinx), не забудем об этом при планировании разработки Интернет сайта.
Sphinx для Drupal 6 есть и нормально работает. Даже dev-версия довольно стабильна.

Infanty 13 июл 2009 в 19:04

Пару месяцев назад стабильной версии не было, а dev не у всех работал.

seaji 13 июл 2009 в 22:49

Предлагаю самый верный способ оптимизации Drupal.
Нужно его портировать с PHP в питон
:)

SamDark 14 июл 2009 в 15:53

И будет ровно то же, если портировать 1 в 1. Узкое место Drupal отнюдь не PHP.

seaji 14 июл 2009 в 23:09

Мои тесты показывают, что для старта PHP нужно 700 мс, а для отработки логики Друпала 100 мс.
Вы, конечно, можете утверждать, что слабое место не PHP, но цифры то говорят обратное.
У Вас другие цифры?

SamDark 14 июл 2009 в 23:13

700 мс для старта PHP?! У меня блог отрабатывает полностью за ~30 мс. Не Drupal, конечно, но PHP.

seaji 14 июл 2009 в 23:27

Вот интересно, почему Вы сказали:
«Не Drupal, конечно»
Потому, что Друпал, конечно, не может выдать таких скоростей?

Понимаете, если Вы напишете на странице print 'Hello Word' — это одна скорость
Если запустите Друпал — это другая.
PHP нужно воспринимать не обособленно, а в связке с Друпалом.

SamDark 14 июл 2009 в 23:53

Нет. Потому, что лень берёт своё…

Вот Drupal6 прилично завешанный модулями с парой тысяч нод:

Concurrency Level: 10
Time taken for tests: 9.610599 seconds
Complete requests: 200
Failed requests: 0
Write errors: 0
Total transferred: 1572400 bytes
HTML transferred: 1478200 bytes
Requests per second: 20.81 [#/sec] (mean)
Time per request: 480.530 [ms] (mean)
Time per request: 48.053 [ms] (mean, across all concurrent requests)
Transfer rate: 159.72 [Kbytes/sec] received

seaji 15 июл 2009 в 13:28

Это общая температура по больнице.
У Вас 400 мс, у меня 800 мс — это говорит только о том, что у Вас железо лучше или акселератор стоит.
Я же имел ввиду разные стадии работы Друпала.
Можете посмотреть www.be-in.ru/journal (там только журнал, открытая студия, форум и стрит фешен на Друпале).
Я там внизу странички подписал цифры. Первая цифра — старт Друпала, все инклюды. Вторая цифра — отработка логики страницы (пункта меню). Третья цифра — темизация. Четвертая цифра — выполнение exit процедур.

SamDark 15 июл 2009 в 13:41

Естественно xcache стоит. Не ставить его — это довольно странное решение. Поставьте и первая цифра у вас значительно упадёт.

egorinsk 15 июл 2009 в 00:41

PHP при использовании в связке с апачем фактически стартует только один раз, а далее только обрабатывает запросы, и ему не надо перечитывать конфиг при каждом запросе к примеру. Так что время запуска php ничего не значит, хоть 700 мс, хоть 15 минут.

seaji 15 июл 2009 в 13:09

Я имел ввиду немного другое. 700 мс на отработку всех необходимых инклюдов.

egorinsk 15 июл 2009 в 20:43

Zend Framework'ом видимо балуетесь? :)) сами виноваты тогда. И не юзаете кешер опкодов? Виноваты 2 раза.

curt 14 июл 2009 в 20:23

на php есть wikipedia и facebook и они не просятся на питон сильно :)

НЛО прилетело и опубликовало эту надпись здесь

Infanty 28 июл 2009 в 09:29

Ну тогда уж сразу на C++ или Pascal :)

XmasterX 14 июл 2009 в 01:20

Зачем использовать еще один модуль (poormanscron) если есть крон cpanel-и?

andreypaa 14 июл 2009 в 08:58

Этот модуль как раз для сайтов, у которых не только в панельки, но и вообще нет возможности использовать стандартный cron.

XmasterX 14 июл 2009 в 11:49

Ясно. Спасибо.

danSamara 19 июл 2009 в 20:28

это статья я вно не про бесплатный шаред с бедными панельками.
весьма странное сочетание: «poormanscron» и «sudo make»

Infanty 28 июл 2009 в 09:32

Пытались перевести наиболее распространённые примеры оптимизации Drupal. Не на всех дешёвых или бесплатных хостингах есть панельки управления.

НЛО прилетело и опубликовало эту надпись здесь

Infanty 28 июл 2009 в 09:33

Пожалуйста.

GogA 14 июл 2009 в 20:47

Статья хорошая, тема актуальна постоянно.
Спасибо.

Особо приятно что автор — представительница прекрасного пола, Елена, большое Вам спасибо!

baroleg 14 июл 2009 в 21:33

Спасибо большое за статью!
Давно искал такое описание

egorinsk 14 июл 2009 в 21:51

Странно, мне кажется, после прочтения этого материала желание работать с Друпалом точно пропадет. Такие извраты.

НЛО прилетело и опубликовало эту надпись здесь

egorinsk 14 июл 2009 в 23:33

Тогда уж лучше пройти через какой-нибудь MVC фреймворк… причем лучше не на php.

НЛО прилетело и опубликовало эту надпись здесь

egorinsk 15 июл 2009 в 21:00

Миллионы не заглядывали в код видимо. Ориентироваться на код, нгаписанный в стиле перловых самописных скриптов 90-х… не уверен, что стоит. Проблема Друпала — наследованный старый, кое-как написанный код. Еще и на функциях с глобальными переменными… фи, неужели не проще спрятать данные и методы в объекты, чем так извращаться?

danSamara 19 июл 2009 в 20:38

Давайте не будем сравнивать друпал со сферической cms в вакууме.
У Вас есть конкретные предентенты на сравнение с друпал?

Sashko 15 июл 2009 в 16:39

а меня сподвигло на установку мемкеша, а я так боялся…

Infanty 28 июл 2009 в 09:35

А Вы поработайте с чужой самописной или покупной CMS — у половины из них нет таких возможностей оптимизации, поэтому они очень кушают процессорное время.

egorinsk 28 июл 2009 в 18:27

Но это же ужасно, как можно продавать некачественные CMS за деньги? (и еще я не могу представить как написать более медленную CMS чем Друпал, это надо очень постараться)

Infanty 28 июл 2009 в 22:48

Не буду разводить холивар, но чуть ли не каждая 2 платная cms…

kleale 14 июл 2009 в 22:04

Drupal'у ничего не поможет, на большей нагрузке с его дибильными мелкими запросами к базе по каждой мелочи при любом чихе…
Если на друпале реализовывать красивый и «многосервисный» проект — любой сервак загнется. Проверено на своем опыте. После года на друпале весь проект придется переносить на свою цмску ибо друпал из-за своей универсальности и нагроможденности модулей и немного странной логики в базе не дает расти проекту. При увеличении ЗАРЕГИСТРИРОВАННЫХ пользователей свыше 1000 в день дает ощутимую нагрузку на довольно мощный сервер (притом база и фротенд разнесены на разные сервера).

Pilat 14 июл 2009 в 22:53

С другой стороны mysqlproxy позволит масштабировать mysql сервер, так что путём небольших затрат мы получим вполне рабочую систему.

korzhik 15 июл 2009 в 00:31

вы наверное удивитесь, но к примеру ubuntu.com работает на друпале.

kleale 15 июл 2009 в 01:49

Я очень рад за убунту.ком, и за сам конкретно переписанный друпал.ком (который при нагрузке сам иногда отключает поиск и другие второстепенные модули) — проектов на друпале много, не спорю.
Я не зря сказал про Зарегистрированных юзеров. Друпал тяжело работает с большим колличеством залогиненных юзеров — стандартный кеш для них не работает и множество других кеширующих модулей, помогает только мемкеш.
Итого хоть друпал разрабатывался для социалок, для них он и не применим из-за реализации обращений к базе данных.

НЛО прилетело и опубликовало эту надпись здесь

Infanty 28 июл 2009 в 09:36

> При увеличении ЗАРЕГИСТРИРОВАННЫХ пользователей свыше 1000 в день
Батенька вы либо не умеете капитализировать Ваш сайт, либо жмот :)

НЛО прилетело и опубликовало эту надпись здесь

mcm69 15 июл 2009 в 16:57

довольная cms [x]

Floks 15 июл 2009 в 22:11

При использовании модуля для кэширования авторизированных пользователей, обязательно править шаблоны и использовать указанные вами переменные? или эффект будет и без этого?