Software Engineer
0,0
рейтинг
13 июля 2009 в 05:02

Разработка → Оптимизация Drupal

Вступление
Drupal – довольная распространённая CMS и это отложило на неё свой отпечаток – базовая поставка Drupal является не готовым решением для определённого вида сайта, а фундаментом для его создания. Существуют “сборки” на базе Drupal специализированные под определённые виды сайтов, например: новостные сайты. Но подобные сборки в данный момент мало распространены и плохо поддерживаются. В связи с этим при создании Интернет сайта на основе стандартной поставки Drupal используется большое количество готовых дополнительные модулей и тем оформления для Drupal, либо разрабатываются новые модули и темы специально для создаваемого Интернет сайта. Последним этапом работ по созданию сайта является его оптимизация, которую условно можно разбить на 4 шага:
  • встроенная оптимизация Drupal;
  • оптимизация Drupal с помощью модулей;
  • оптимизация конфигурации и обслуживания Drupal;
  • оптимизация сервера.

Встроенная оптимизация Drupal

1. Отключим все неиспользуемые модули. Так как при генерации страницы перед отправкой её браузеру пользователя код определённых модулей может выполняться, даже если функционал данного модуля не используется на сайте. На выполнение кода будет тратиться процессорное время сервера, что приведёт к более долгой генерации страницы. Пример такого модуля – Statistics. Вместо статистики выдаваемой данным модулем, можно использовать статистику сервиса — Google Analytics.         

2. При создании сайта используем Drupal версии 6, так как в нём лучше реализованы внутренние средства кэширования. Так же в дополнительных модулях (Views, Panel и т.д.) для Drupal версии 6 внедрены эффективные методы кэширования. К сожалению не все модули Drupal версии 5 реализованы для Drupal версии 6 (например, модуль Sphinx), не забудем об этом при планировании разработки Интернет сайта. Далее будем рассматривать только Drupal версии 6.

3. Хорошо обдумаем варианты использования модулей на подобии CCK (Content Construction Kit), перед реализацией запланированного при создании сайта. Например, простая задача на хранение в базе сайта тысячи типов продуктов, их названий и описаний, решается с помощью:
  • создания тысячи терминов таксономии и привязки их к определённому типу материала,
  • добавления определённому материалу дополнительного поля CCK в котором будет храниться тип продуктов.

При усложнении задачи с помощью условия, что все типы продуктов должны быть разбиты на 10 групп, задача решается двумя вариантам. Вариант первый, с использованием таксономии:
  • Таксономия позволяет создавать иерархию терминов в словаре, т.е. в словаре с терминами может быть 10 терминов первого уровня, а остальные термины будут потомками одного из этих 10 терминов. Создадим нужную иерархию терминов в словаре.
  • Установим дополнительный модуль — Hierarchical Select (http://drupal.org/project/hierarchical_select), который позволяет в зависимости от вложенности уровней словаря таксономии отображать определённое количество выпадающих с писков. Т.е. пользователю при добавлении новой статьи о продукте на сайт, будет выведен один выпадающий список, в котором можно выбрать один из 10 терминов первого уровня (группы типов продуктов). После осуществления выбора, пользователю будет отображён ещё один выпадающий список, в котором будут отображены потомки данного термина в иерархическом дереве терминов данного словаря таксономии (типы продуктов).

Вариант второй, с использованием CCK:
  • Необходимо определённому материалу добавить 2 дополнительных поля CCK, одно для хранения групп продуктов, второе для хранения типов продуктов.
  • Нужно настроить взаимодействие данных полей в зависимости от выбора значений в них.

Главная ошибка при решении подобных задач создающая дополнительную нагрузку на базу данных:
  • создание у определённого материала 10 полей CCK, по полю на каждую группу;
  • при создании у определённого материала поля CCK, не указана его длина (поэтому по умолчанию считается, что она максимально возможная).

4. Используем встроенное кэширование Drupal. Оно позволяет кэшировать информацию, извлечённую из базы данных, а так же информацию, полученную при обработке извлечённой информации из PHP.

Кэширование системы меню, фильтров форматов ввода, переменных администрирования (например: название сайта) и настроек модуля — производится автоматически. Остальные параметры кэширования можно настроить на странице: Управление -> Производительность (http://www.example.ru/admin/settings/performance).

На данной странице можно настроить:
  • компрессиию страниц;
  • кеширование блоков;
  • оптимизацию CSS файлов;
  • оптимизацию JavaScript файлов.

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

При включении кэширования страниц в режим – агрессивный, при генерации страницы пропускается загрузка и выгрузка включенных модулей, поэтому часть модулей могут работать некорректно или не работать совсем.

Настроим минимальное время жизни кэша страниц для анонимных пользователей. Данный параметр определяет, через какое время после кэширования страницы, производится проверка на то обновлено ли содержимое данной страницы или нет. Если обновлено, то кэш данной страницы очищается. Т.е. если администратор сайта изменил содержимое страницы, он его увидит сразу, а анонимные пользователи, только по прошествии минимальное время жизни кэша.   

Включим компрессию страниц, для сохранения сжатого кэша страниц и для передачи страницы браузеру пользователя в сжатом виде, если он поддерживает компрессию gzip. Компрессия производится с помощью библиотеки zlib установленной как расширение в PHP.

Включим кэширование блоков. Принцип работы кэширования блоков аналогичен принципу кэширования страниц. Для супер — пользователя (первого зарегистрированного пользователя при установке Drupal, его id равен 1) блоки никогда не кэшируются.

Включим оптимизацию CSS и JavaScript файлов. Это уменьшит их размер и количество обращений к серверу при загрузке страниц в браузер. Все CSS и JavaScript файлы собираются в один (свой файл для CSS и свой — для JavaScript). Что уменьшает количество обращений к серверу при загрузке страницы.

Оптимизация Drupal с помощью модулей

1. Установим модуль Authenticated User Page Caching (Authcache), скачать его можно по Интернет адресу — http://drupal.org/project/authcache. Данный модуль позволяет кэшировать страницы, как для анонимных пользователей, так и для аутентифицированных (“залогинившихся”) пользователей более качественно чем встроенное кэширование Drupal. При установке данного модуля, необходимо перенастроить динамический контент на страницах (например: вывод имени аутентифицированного пользователя).

Authcache сохраняет сжатый кэш страниц отдельно для каждого пользователя или роли. Кэш сохраняется в базе данных или в стороннем средстве кэширования (memcahed, APC, и т.д.). Кэшированные версии страниц для аутентифицированных пользователей (кроме супер — пользователя) передаются с помощью AJAX, поэтому достигается очень быстрое отображение страницы в браузере. Если у аутентифицированного пользователя в браузере отключены JavaScript, то он получает страницы не из кэша. На некоторых серверах скорость загрузки страницы уменьшается до 1 миллисекунды.

Для установки модуля:
  • скачаем его;
  • распакуем модуль в папку /sites/all/modules;
  • скопируем файл ajax_authcache.php из папки модуля в корневую директорию сайта (там же находится файл index.php);
  • откроем файл settings.php (в папке /sites/default) и добавим следующий код (без примечаний за // …) в начало файла после тега <?php:

$conf['cache_inc'] = './sites/all/modules/authcache/api/authcache.inc';
$conf['authcache'] = array(
  'default' => array(
    // технология кеширования — apc, memcache, db, file, eacc or xcache
    'engine' => 'db',   
    // если используем memcached (host:port, e..g, 'localhost:11211')
    'server' => array(),   
    // если используем memcached shared single process 
    'shared' => TRUE,  
    // кэш ключа префикса (для нескольких сайтов)                 
    'prefix' => '', 
    // если используем кеширование на файлах – указываем путь их
    // сохранения             
    'path' => 'files/filecache', 
    // static array cache (advanced) // статический массив кэша (расширенный)
    'static' => FALSE,           
  ),
);

В данном коде устанавливаются настройки модуля Authcache. Указываем, что будем хранить кэш страниц в базе данных ('engine' => 'db'), поэтому все остальные установки не имеют значения, оставляем их без изменений. Более подробно о параметрах данного кода можно прочитать на странице — http://drupal.org/project/cacherouter (на английском языке).

Включим модуль Authcache на странице: Управление -> Модули (http://www.example.ru/admin/build/modules). После чего настроим его работу на странице: Управление -> Производительность -> Authcache (http://www.example.ru/admin/settings/performance/authcache):
  • укажем роли, для которых необходимо кэшировать контент;
  • аннулируем все пользовательские сессии (чекбокс — Invalidate all user sessions) при первом запуске;
  • выставив время хранения кэша (в часах);
  • нажмём кнопку сохранить и очистить кеш (Save & clear cached pages), для сохранения изменений.


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

В шаблонах тем оформления используем переменные:
  • $user_name – для отображения имени аутентифицированного пользователя;
  • $user_link – для отображения ссылок связанных с профилем пользователя;
  • $is_page_authcache — если установлен в TRUE то все хуки данного шаблона темы оформления будут сохранены в кеш.

Можно так же ознакомится с примером – /sites/all/modules/authcache/modules/authcache_example, который показывает как настроить блоки с пользовательским содержанием (с контентом пользователя).

2. Если необходимо кэшировать страницы только для анонимных пользователей (без аутентифицированных), можно установить модуль Cache Router. Данный модуль лежит в основе модуля Authcache и кэширует страницы лучше встроенного кэширования Drupal. Скачаем модуль по Интернет адресу — http://drupal.org/project/authcache. После скачивания распакуем модуль в папку /sites/all/modules. Включим модуль Cache Router на странице: Управление -> Модули (http://www.example.ru/admin/build/modules). Откроем файл settings.php (в папке /sites/default) и добавим следующий код в начало файла перед тегом <?php:

$conf['cache_inc'] = './sites/all/modules/cacherouter/cacherouter.inc';
$conf['cacherouter'] = array(
  'default' => array(
    'engine' => 'db',
    'server' => array(),
    'shared' => TRUE,
    'prefix' => '',
    'path' => 'sites/default/files/filecache',
    'static' => FALSE,
    'fast_cache' => TRUE,
  ),
);

3. После осуществлений действий приведенных выше, страницы создаваемого сайта будут отдаваться сервером браузеру пользователя в сжатом виде, а вот CSS и JavaScript нет. Исправим это:
  • cкачаем модуль  CSS Gzip со страницы — http://drupal.org/project/css_gzip;
  • cкачаем модуль JavaScript Aggregator со страницы — http://drupal.org/project/javascript_aggregator;
  • распакуем модули в папку /sites/all/modules;
  • включим модули на странице: Управление -> Модули (http://www.example.ru/admin/build/modules);
  • активируем сжатие CSS и JavaScript на странице: Управление -> Производительность (http://www.example.ru/admin/settings/performance), отметив чекбоксы — GZip CSS и GZip JavaScript;
  • внесём изменение в файл .htaccess расположенный в корневой директории сайта (на основании данных из README.txt входящего в состав модуля CSS Gzip), пропишем меду тегами <IfModule mod_rewrite.c> и </IfModule> следующий код:

 ### START CSS GZIP ###
 # Requires mod_mime to be enabled.
 <IfModule mod_mime.c>
    # Send any files ending in .gz with x-gzip encoding in the header.
    AddEncoding x-gzip .gz
 </IfModule>
 # Gzip compressed css files are of the type 'text/css'.
 <FilesMatch "\.css\.gz$">
    ForceType text/css
 </FilesMatch>
 <IfModule mod_rewrite.c>
    RewriteEngine on
    # Serve gzip compressed css files
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.css $1\.css\.gz [L,QSA,T=text/css]
 </IfModule>
 ### End CSS GZIP ###
  • сохраним настройки и очистим кэш.

Если в шаблонах темы оформления необходимо использовать дополнительные CSS и JavaScript, желательно подключать их с помощью команд:
  • drupal_add_css('путь к CSS относительно корневой директории сайта');
  • drupal_add_js('путь к JavaScript относительно корневой директории сайта');

для того, что бы они оптимизировались (включались в один исходный CSS или JavaScript файл) и сжимались, совместно со всеми остальными CSS или JavaScript файлами, используемыми на сайте.

Оптимизация конфигурации и обслуживания Drupal

От оптимизации Drupal с помощью модулей, перейдём к более сложной оптимизации – оптимизации конфигурации и обслуживания Drupal.

1. Уменьшим время хранения пользовательских сеансов. Так как Drupal хранит их в своей базе данных, то сокращение времени их хранения разгрузит базу данных, особенно если на сайт приходят тысячи пользователей в день. По умолчанию сеансы хранятся 55 часов, уменьшим время их хранения до 24 часов. Для этого на сервере в папке /sites/default в файле settings.php изменим строку:

ini_set('session.gc_maxlifetime',   200000);

на:

ini_set('session.gc_maxlifetime',   86400); // 24 часа (в секундах)

Так же в этом файле можно сократить время жизни кэшированных страниц сеансов до 24 часов, изменив строку:

ini_set('session.cache_expire',   200000);

на:

ini_set('session.cache_expire',     1440); // 24 часа (в минутах)

На последок в этом же файле изменим время хранения cookie в браузере пользователя, сократив его до 24 часов:

ini_set('session.cookie_lifetime', 86400); // 24 часа (в секундах)

Если установить время хранения cookie в браузере пользователя равным 0 – то cookie будет удаляться сразу после закрытия Интернет браузера пользователем.

2. Сократим количество сообщений протоколирования работы сайта, сохраняемых в базе данных. На странице: Управление -> Отчеты и сообщения -> Отчеты в базе данных (http://www.example.ru/admin/settings/logging/dblog), выставим необходимый максимум отчётов хранимых в базе данных. Данные отчёты полезны для просмотра попыток взлома сайта, поэтому минимум, который можно выбрать, это 100 записей. Просмотреть данные отчёты можно перейдя на страницу Управление -> Недавние записи в системном журнале (http://www.example.ru/admin/reports/dblog).

3. Настроим выполнение регулярных процедур (задачи cron), так как при их выполнении очищаются журналы записей сообщений протоколирования работы сайта, устаревшие записи кэша и другие статистические данные. Самым простым способом настройки автоматического запуска регулярных процедур является установка модуля – Poormanscron. Скачаем данный модуль по Интернет адресу — http://drupal.org/project/poormanscron. Распакуем его в папку /sites/all/modules, активируем модуль на странице: Управление -> Модули (http://www.example.ru/admin/build/modules).  Установим интервал запусков Cron на странице: Управление -> Poormanscron (http://www.example.ru/admin/settings/poormanscron) равным 360 минут (один раз в 6 часов).

4. В составе Drupal имеется модуль Throttle, который производит оценку количества посетителей сайта и отключает некоторые функциональные возможности, если достигнут порог, установленный администратором. После активации модуля на странице: Управление -> Модули (http://www.example.ru/admin/build/modules), можно увидеть, что у некоторых модулей на данной странице кроме флажков включения появились флажки —  должен ли данный модуль регулироваться Throttle или нет. Так же некоторые блоки могут регулироваться Throttle (Управление -> Блоки (http://www.example.ru/admin/build/block)). Настройка Throttle производятся на странице Управление -> Регулятор (http://www.example.ru/admin/settings/throttle), где производится указывание минимального количества анонимных посетителей и минимальное количество зарегистрированных пользователей для включения ограничения функционала сайта для них. На этой странице так же установим вероятностный ограничитель авторегулятора на 20%, для того чтобы для одного из каждых 5 запросов на выдачу страницы браузеру пользователю, производился запрос к базе данных для определения нагрузки на сайт.    

Оптимизация сервера

Так как сервер сайта может работать под управлением разных операционных систем:
  • Windows,
  • Lunux,
  • FreeBSD,

то в каждом случае настройки оптимизации сервера будут отличаться (т.е. установка eAccelerator в Windows и Lunux сильно различается). Ниже приведены только основные рекомендации по оптимизации сервера. Подробно из рекомендаций рассмотрена только установка PHP-акселератора на сервер Ubuntu 8.04, так как PHP-акселератор значительно ускоряет работу сайта.

1. Установим eAccelerator, он является PHP-акселератором, основное назначение которого состоит в кэшировании бинарного представления кода.

Соединимся с сервером по SSH и авторизуемся с правами root. Выполним команды для установки дополнительного пакета php5-dev:

sudo apt-get install php5-dev
sudo apt-get install make

Выполним команды для установки eAccelerator:

sudo cd /tmp/
sudo wget bart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2
sudo tar xvjf eaccelerator-0.9.5.3.tar.bz2
sudo cd eaccelerator-0.9.5.3
sudo phpize
sudo ./configure --enable-eaccelerator=shared
sudo make
sudo make install

Отредактируем файл php.ini в папке /etc/php5/apache2, вставим в начале файла после тега [PHP] код:

; eAccelerator configuration
; Note that eAccelerator may also be installed as a PHP extension or as a zend_extension
; If you are using a thread safe build of PHP you must use
; zend_extension_ts instead of zend_extension
;extension                                   = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
zend_extension                          = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
eaccelerator.shm_size                = "16"
eaccelerator.cache_dir                = "/var/cache/eaccelerator"
eaccelerator.enable                      = "1"
eaccelerator.optimizer                 = "1"
eaccelerator.check_mtime           = "1"
eaccelerator.debug                        = "0"
eaccelerator.filter                          = ""
eaccelerator.shm_max                  = "0"
eaccelerator.shm_ttl                      = "0"
eaccelerator.shm_prune_period    = "0"
eaccelerator.shm_only                  = "0"
eaccelerator.compress                   = "1"
eaccelerator.compress_level          = "9"
eaccelerator.allowed_admin_path = "/var/www/eaccelerator"

При использовании Zend Optimizer и / или ionCube Loader, приведенный выше код будет выглядеть так:

; eAccelerator configuration
; Note that eAccelerator may also be installed as a PHP extension or as a zend_extension
; If you are using a thread safe build of PHP you must use
; zend_extension_ts instead of zend_extension
;extension                       = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
zend_extension                  = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
eaccelerator.shm_size           = "16"
eaccelerator.cache_dir          = "/var/cache/eaccelerator"
eaccelerator.enable             = "1"
eaccelerator.optimizer          = "1"
eaccelerator.check_mtime        = "1"
eaccelerator.debug              = "0"
eaccelerator.filter             = ""
eaccelerator.shm_max            = "0"
eaccelerator.shm_ttl            = "0"
eaccelerator.shm_prune_period   = "0"
eaccelerator.shm_only           = "0"
eaccelerator.compress           = "1"
eaccelerator.compress_level     = "9"
eaccelerator.allowed_admin_path = "/var/www/eaccelerator"

; ionCube Loader configuration
zend_extension=/usr/local/lib/ioncube/ioncube_loader_lin_5.2.so

; Zend Optimizer configuration
zend_extension=/usr/local/lib/Zend/ZendOptimizer.so
zend_optimizer.optimization_level=15

Создадим кэш каталог для eAccelerator выполнив команды:

sudo mkdir -p /var/cache/eaccelerator
sudo chmod 0777 /var/cache/eaccelerator

Перезапустим Apache:

sudo /etc/init.d/apache2 restart

2. Рекомендуем установить Web-сервер nginx и настроить его работу с Web-сервером Apache так, чтобы страницы отдавал браузеру пользователя Apache, а статический контент (CSS, JavaScript, фото и т.д.) nginx. Либо полностью заменить Web-сервер Apache, Web-сервером nginx.

3. Установим в Apache модуль mod_expires, который позволяет Drupal посылать HTTP-заголовки Expires, кэшируя все статические файлы (изображения, css, javascript и т.п.) в Интернет браузере пользователя на определённый срок или до момента появления новых версий файлов. Настройки взаимодействия Drupal и модуля mod_expires Web-сервера Apache, находится в файле .htaccess в корневой директории сайта:

# Включить mod_expires.
<IfModule mod_expires.c>
 # Разрешить истечение срока.
 ExpiresActive On

 # Кэшировать все файлы на две недели после доступа (A).
 ExpiresDefault A1209600

 # Не кэшировать динамически генерируемые страницы.
 ExpiresByType text/html A1
</IfModule>

4. Для ускорения обработки .htaccess файлов web-сервером их содержание можно перенести в главный файл конфигурации Apache – httpd.conf. После чего необходимо запретить поиск файлов .htaccess в пределах корневого каталога web-сервера, установив AllowOverride в None:

<Directory/>  
 AllowOverride
 …
</Directory>  

В виду того, что некоторые модули внутри своих каталогов могут содержать .htaccess файлы, следует аккуратно работать с данным видом оптимизации, что бы при переносе содержимого всех .htaccess файлов в httpd.conf, не пропустить не один .htaccess файл.

5. Установим на сервере:
  • систему анализа лог файлов (например: AWstats),
  • систему мониторинга производительности сервера (например: Munin);
  • систему для учета сетевого трафика (например: Vnstat).


6. Включим кэш MySQL и установим его размер равным 64 мегабайтам. Для этого отредактируем файл my.cnf в папке /etc/mysql (при использовании Ubuntu 8.04). Изменим значение:

# query_cache_limit        = 1M
# query_cache_size        = 16M

на:

query_cache_limit        = 1M
query_cache_size        = 64M

После чего перезапустим MySQL командой:

/etc/init.d/mysql restart

Слишком маленький размер кэша – малоэффективен, а слишком большой размер кэша приводит к тому, что поиск нужной информации в кэше производится большое время. Поэтому рекомендуем поэкспериментировать с размером кэша, на каждом конкретном сервере и подобрать его оптимальный размер.

7. Проверим – загрузку центрального процессора, нехватку оперативной памяти или места на диске и возможную перегрузку линии связи сервера с Интернет. Если необходимо разместим Базу данных на отдельном сервере, для этого изменим, настройки соединения с базой данных находятся в файле settings.php (в папке /sites/default). Либо разместим сайт на кластере из серверов (например: воспользовавшись услуги сервиса Amazon C2).  

Заключение

Для просмотра информации о сервере из Drupal существует удобный модуль — System information (http://drupal.org/project/systeminfo). После его установки и активации информацию о вашем сервере можно посмотреть на странице — http://www.example.ru/admin/reports/systeminfo.

Для тестирования скорости работы сайта и оптимизации его контента очень удобно пользоваться плагин YSlow для Интернет браузера Firefox, который показывает подробную статистику по загрузке страниц с вашего сайта.

Обновлённая версия статьи разбитая на главы, доступна на сайте: http://www.mydrupalbook.ru/ .

Автор: Цаплина Елена & Вячеслав
Вячеслав К. @Infanty
карма
23,0
рейтинг 0,0
Software Engineer
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • 0
    Очень хорошая статья… скоро сдам проект и начну заниматься оптимизацией.
  • +3
    Спасибо за статью
    однако, Пример такого ненужного модуля – Statistics. Вместо статистики выдаваемой данным модулем, можно использовать статистику сервиса — Google Analytics.

    а количество просмотров данной ноды ГА тоже может выдать пользователю?
    • 0
      Может
      • +2
        расскажите как?
        выдать именно пользователю, а не человеку с доступом в ГА :)
        p.s. Заодно вывод наиболее популярных материалов в разбивке по типу (например, полуярные записи в блогах, популярные темы форума и тд)
        • +2
          Простите, не сконцентрировал внимание на «выдать пользователю» :)
          Но в любом случае, в GA можно дать доступ пользователю ко всем отчётам через Диспечер пользователей. Не исключаю, что через API это тоже можно сделать.
        • +1
          Google Analytics Tracking API:

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

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

    • 0
      Многим хватает отображения количества посещений за сутки, с этим прекрасно справляется Google Analytics (при условии очень медленного сервера).
      • 0
        Ну, тогда уж счетчик livinternet ставить
        хотя конечно дело вкуса
  • +1
    Если что — я продаю VDS оптимизированные под Drupal. nginx+php-fpm+memcache. Сайты просто летают. А апач выкинут ибо ненужен.
    Пишите в хабрапочту

    • 0
      Одесский, сколько на одном вдс оперативной?
      • 0
        От 256mb до 2G :)
  • +1
    Странно что автор не упомянл о смене движка кэширования с БД на memcache — даже если опустить все остальные виды оптимизации со стороны сервера, замена хранилища кэша на мэмкэш сразу же дает идимы приросто производительности при второй и последующих загрузках страниц (элментов страниц).
    • +1
      Это и так все знают… Интересна первая часть, где рассказывается именно о настройках Друпала. Оптимизация сервера — это не только для него, но и для других CMS тоже подойдет.
      • +2
        В Authcache можно использовать движок memcache или как в примере — всё хранить в БД.
  • +1
    Про Cacherouter забыли — а ведь если на сервере хорошая дисковая подсистема, можно перевести кеш из базы на файлы. Я уж молчу о разделении кешей.
    • +1
      2. Если необходимо кэшировать страницы только для анонимных пользователей (без аутентифицированных), можно установить модуль Cache Router — пропустили по тексту наверное.
      • +1
        И у аутентифицированных есть чего кешировать. А вот как раз насчет Authcache я сильно сомневаюсь. Визуально — да, будет быстрее. А подгружать информацию для самого пользователя и прочее — сколько еще запросов к базе надо совершить?
        • 0
          Authcache — он как раз и кэширует инфу у каждого зарегистрированного пользователя.
          • 0
            Он АЯКСом подгружает измененное. Ускорение чисто визуальное, серверу только хуже. Лично я предпочитаю вторгаться в структуру БД при помощи hook_schema_alter для некоторых запросов. Для числа новых комментариев, например. В друпале есть чего ускорять, но точно не при помощи Authcache.
            • 0
              Ускорение практическое, а не визуальное, тестирование Вам всё покажет. Вторгаться в структуру БД и в ядро Drupal — это строить не портируемое решение, проще сразу на C++ всё написать.
  • 0
    >К сожалению не все модули Drupal версии 5 реализованы для Drupal версии 6 (например, модуль Sphinx), не забудем об этом при планировании разработки Интернет сайта.
    Sphinx для Drupal 6 есть и нормально работает. Даже dev-версия довольно стабильна.
    • +1
      Пару месяцев назад стабильной версии не было, а dev не у всех работал.
  • –11
    Предлагаю самый верный способ оптимизации Drupal.
    Нужно его портировать с PHP в питон
    :)
    • 0
      И будет ровно то же, если портировать 1 в 1. Узкое место Drupal отнюдь не PHP.
      • –1
        Мои тесты показывают, что для старта PHP нужно 700 мс, а для отработки логики Друпала 100 мс.
        Вы, конечно, можете утверждать, что слабое место не PHP, но цифры то говорят обратное.
        У Вас другие цифры?
        • 0
          700 мс для старта PHP?! У меня блог отрабатывает полностью за ~30 мс. Не Drupal, конечно, но PHP.
          • 0
            Вот интересно, почему Вы сказали:
            «Не Drupal, конечно»
            Потому, что Друпал, конечно, не может выдать таких скоростей?

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

              Вот 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
              • 0
                Это общая температура по больнице.
                У Вас 400 мс, у меня 800 мс — это говорит только о том, что у Вас железо лучше или акселератор стоит.
                Я же имел ввиду разные стадии работы Друпала.
                Можете посмотреть www.be-in.ru/journal (там только журнал, открытая студия, форум и стрит фешен на Друпале).
                Я там внизу странички подписал цифры. Первая цифра — старт Друпала, все инклюды. Вторая цифра — отработка логики страницы (пункта меню). Третья цифра — темизация. Четвертая цифра — выполнение exit процедур.
                • 0
                  Естественно xcache стоит. Не ставить его — это довольно странное решение. Поставьте и первая цифра у вас значительно упадёт.
        • 0
          PHP при использовании в связке с апачем фактически стартует только один раз, а далее только обрабатывает запросы, и ему не надо перечитывать конфиг при каждом запросе к примеру. Так что время запуска php ничего не значит, хоть 700 мс, хоть 15 минут.
          • 0
            Я имел ввиду немного другое. 700 мс на отработку всех необходимых инклюдов.
            • 0
              Zend Framework'ом видимо балуетесь? :)) сами виноваты тогда. И не юзаете кешер опкодов? Виноваты 2 раза.
    • 0
      на php есть wikipedia и facebook и они не просятся на питон сильно :)
    • –1
      а почему сразу не на ассемблер?
      • 0
        нет, правда.
        зачем переписывать на питон? особенно сохраняю структуру, которая сейчас. тогда уж имеет смысл писать что-то новое. а даже если бы портировали ядро, модули бы никто не стал переписывать на новый язык.
        как говорилось где-то (на drupal.ru?) в друпале уже и так многое-многое оптимизировано, но решения по хранению кэша в БД, а так же файлов перевода и ещё многой фигни (хорошо хоть файлы туда не пишут =) ) лично меня несколько пугают.
        для нормальной работы нужно ставить devel и пилить, пилить, пилить — а потом выйдет обновление — и опять заново пилить то, что изменилось.

        кстати, по поиску видно, что не только автора волнует эта проблема:
        www.google.ru/search?hl=ru&newwindow=1&q=site:http://drupal.ru/+оптимизация&btnG=Поиск&lr=&aq=f&oq=
    • 0
      Ну тогда уж сразу на C++ или Pascal :)
  • 0
    Зачем использовать еще один модуль (poormanscron) если есть крон cpanel-и?
    • +2
      Этот модуль как раз для сайтов, у которых не только в панельки, но и вообще нет возможности использовать стандартный cron.
      • 0
        Ясно. Спасибо.
      • 0
        это статья я вно не про бесплатный шаред с бедными панельками.
        весьма странное сочетание: «poormanscron» и «sudo make»
        • 0
          Пытались перевести наиболее распространённые примеры оптимизации Drupal. Не на всех дешёвых или бесплатных хостингах есть панельки управления.
  • 0
    ой, какая больная тема.
    и сколько статей про неё было на drupal.ru.
    Хотя почти ничего нового нет, но спасибо — удобно читать про все методы в одном месте.
    • 0
      Пожалуйста.
  • +1
    Статья хорошая, тема актуальна постоянно.
    Спасибо.

    Особо приятно что автор — представительница прекрасного пола, Елена, большое Вам спасибо!
  • 0
    Спасибо большое за статью!
    Давно искал такое описание
  • +4
    Странно, мне кажется, после прочтения этого материала желание работать с Друпалом точно пропадет. Такие извраты.
    • НЛО прилетело и опубликовало эту надпись здесь
      • –1
        Тогда уж лучше пройти через какой-нибудь MVC фреймворк… причем лучше не на php.
        • НЛО прилетело и опубликовало эту надпись здесь
          • –2
            Миллионы не заглядывали в код видимо. Ориентироваться на код, нгаписанный в стиле перловых самописных скриптов 90-х… не уверен, что стоит. Проблема Друпала — наследованный старый, кое-как написанный код. Еще и на функциях с глобальными переменными… фи, неужели не проще спрятать данные и методы в объекты, чем так извращаться?
            • 0
              Давайте не будем сравнивать друпал со сферической cms в вакууме.
              У Вас есть конкретные предентенты на сравнение с друпал?
    • 0
      а меня сподвигло на установку мемкеша, а я так боялся…
    • 0
      А Вы поработайте с чужой самописной или покупной CMS — у половины из них нет таких возможностей оптимизации, поэтому они очень кушают процессорное время.
      • 0
        Но это же ужасно, как можно продавать некачественные CMS за деньги? (и еще я не могу представить как написать более медленную CMS чем Друпал, это надо очень постараться)
        • 0
          Не буду разводить холивар, но чуть ли не каждая 2 платная cms…
  • 0
    Drupal'у ничего не поможет, на большей нагрузке с его дибильными мелкими запросами к базе по каждой мелочи при любом чихе…
    Если на друпале реализовывать красивый и «многосервисный» проект — любой сервак загнется. Проверено на своем опыте. После года на друпале весь проект придется переносить на свою цмску ибо друпал из-за своей универсальности и нагроможденности модулей и немного странной логики в базе не дает расти проекту. При увеличении ЗАРЕГИСТРИРОВАННЫХ пользователей свыше 1000 в день дает ощутимую нагрузку на довольно мощный сервер (притом база и фротенд разнесены на разные сервера).
    • 0
      С другой стороны mysqlproxy позволит масштабировать mysql сервер, так что путём небольших затрат мы получим вполне рабочую систему.

    • +3
      вы наверное удивитесь, но к примеру ubuntu.com работает на друпале.
      • –3
        Я очень рад за убунту.ком, и за сам конкретно переписанный друпал.ком (который при нагрузке сам иногда отключает поиск и другие второстепенные модули) — проектов на друпале много, не спорю.
        Я не зря сказал про Зарегистрированных юзеров. Друпал тяжело работает с большим колличеством залогиненных юзеров — стандартный кеш для них не работает и множество других кеширующих модулей, помогает только мемкеш.
        Итого хоть друпал разрабатывался для социалок, для них он и не применим из-за реализации обращений к базе данных.
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      > При увеличении ЗАРЕГИСТРИРОВАННЫХ пользователей свыше 1000 в день
      Батенька вы либо не умеете капитализировать Ваш сайт, либо жмот :)
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    довольная cms [x]
  • 0
    При использовании модуля для кэширования авторизированных пользователей, обязательно править шаблоны и использовать указанные вами переменные? или эффект будет и без этого?
    • 0
      Тестируйте и узнаете, у меня вообще переменные для исправления отсутствуют в шаблоне.
  • 0
    Ах да. Про blockcache_alter ни слова нет. А ведь модуль великолепен :) Меня даже патчинг ядра не остановил.
    • 0
      Патчинг ядра — великое зло если это только не Ваш личный сайт. Клиентам ненужен не поддерживаемый сайт который очень трудно обновить.
      • 0
        Естественно зло, кто ж спорит. Только бабло зло побеждает :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.