Оптимизация. Drupal vs Apache

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

Аватар пользователя darkdim darkdim 25 апреля 2010 в 12:53

Сайт грузит и вешает сервер. Описание проблемы тут http://www.drupal.ru/node/43309
Пока решается вопрос о выборе исполнителя на настройку сервера, хочу понять для себя, да и может кому-то пригодиться, в чем кривости, в друпале или в апаче.
Хотя в кривости настроек вебсервера сомнений почти нет... но все же.
Что было замечено - во время запроса сайта создается процесс php-cgi, занимающий память 230М. Когда таких запросов много, даже например при постоянном нажатии F5, начинают "плодиться" процессы, занимающие память и замедляющие работу процессора. Когда таких процессов накапливается много, сервер "подвисает".
На сервере установлен eAccelerator, но техподдержка в открытую созналась, что он как надо не настроен(видимо нет специалиста), и в логи Error сервера идут соответствующие записи:
[Sun Apr 25 10:39:21 2010] [error] [client *.*.*.*] EACCELERATOR hit: "/usr/local/www/data...

Но что еще замечено, на том же сервере работают еще несколько сайтов на самописных цмсках, и со сложными запросами, и с большими по объему базами, но при постоянной посылке запросов нет такого эффекта как с Drupal, когда создается много процессов с большим объемом памяти и загружающих процессор.
Понятно, что архитектура Drupal предполагает работу препроцессора(php код), выполняющего свои функции и занимающего большой объем памяти, но в то же время он(php код) часто выполняет "повторяющиеся" процессы, например "процесс начальной загрузки" и т.д. Очевидно, что одним из выходов, снижающим нагрузку на сервер есть настройка правильной работы eAccelerator, кеширующего работу php, тогда препроцессору не нужно будет выполнять снова и снова один и тот же ресурсоемкий код.

Что бы подтвердить свои догадки я решил немного "разгрузить" сайт.
Во первых я вернул стандартную тему, потому что есть мнение, что кривая тема может влиять на нормальную работу сайта. Еще я повыключал вьювсы, панели, страницы(pages), тоже несущие довольно большую нагрузку. Сайт стал значительно легче, но с учетом того, что этим отключением поубивал все функциональные настройки. Попробовал посылать запросы F5, да, поначалу сервер быстрее обрабатывал процессы, но все равно потом опять "собралась очередь процессов" и сервер стал "задумчивым".
Тот же процесс я опробовал на другом сайте на Drupal, опубликованном ранее, но использующим намного "скромнее" набор используемых модулей. Та же картина.

В результате экспериментов появился ряд вопросов, почему одним движкам "хватает" стандартных настроек апача, и нет необходимости в дополнительной оптимизации работы вебсервера(сюда входит apache+php+mysql), а для сайтов на Drupal все же необходима специфичная дополнительная оптимизация? Это цена гибкости архитектуры Drupal?

Комментарии

Аватар пользователя adubovskoy adubovskoy 25 апреля 2010 в 13:10

это цена друпал-сайта без включенного кэширования) включите кэш, включите кэш у views, Если сайт высоконагруженный - не поленитесь найти человека, который настроит вам nginx + apache связку, нджинкс на раздачу файла - значительно сэкономите память и проц. Отключите все ненужные в продакшене модули (devel, views ui часто оставляют включенными), вообще все ненужные и неискользуемые модули отключите.

"darkdim" wrote:
а для сайтов на Drupal все же необходима специфичная дополнительная оптимизация? Это цена гибкости архитектуры Drupal?

Это в данном конкретном случае что-то не так... Всего хватает.

Аватар пользователя darkdim darkdim 25 апреля 2010 в 14:24

adubovskoy wrote:
это цена друпал-сайта без включенного кэширования) включите кэш, включите кэш у views, Если сайт высоконагруженный - не поленитесь найти человека, который настроит вам nginx + apache связку, нджинкс на раздачу файла - значительно сэкономите память и проц. Отключите все ненужные в продакшене модули (devel, views ui часто оставляют включенными), вообще все ненужные и неискользуемые модули отключите.

"darkdim" wrote:
а для сайтов на Drupal все же необходима специфичная дополнительная оптимизация? Это цена гибкости архитектуры Drupal?

Это в данном конкретном случае что-то не так... Всего хватает.


Сорри, я в этом топике не писал, но писал в предыдущем, что все кеширования включил, а так же включил Authcache, CacheRouter, JavaScript Aggregator, CSS Gzip.
Сайт высоконагруженный, человека не поленился найти, но завязка в том, что одна контора осуществляет техподдержку сервера, и nginx они не в какую не поддерживают. Кроме того они упираются что бы кто-то занимался настройкой, тогда они снимают с себя ответственность за поддержку, необходимо будет искать и поддержку. Усложняется это тем, что владелец сервера организация - юридическое лицо.
devel я вообще не включал до момента неудачной публикации, пока не настала необходимость посмотреть используемые ресурсы.
views ui я пока не отключал, что бы выполнить окончательно тонкую настройку(есть нюансы) на уже запущенном сайте.

Вот что не так и пытаюсь разобраться))

Аватар пользователя Azerot Azerot 25 апреля 2010 в 13:27

Quote:
во время запроса сайта создается процесс php-cgi, занимающий память 230М

Значит PHP работает в режиме CGI, что не очень производительно, хотя и лучше в плане безопасности.
230M - это как бы очень дохрена. Видимо, действительно, много лишнего. Или, например, очень много элементов какого-либо товарного каталога засасывается, хотя реально столько и не нужно.

Quote:
На сервере установлен eAccelerator, но техподдержка в открытую созналась, что он как надо не настроен

eAccelerator не работает в режиме CGI, либо нужен fastCGI либо mod_php

Аватар пользователя darkdim darkdim 25 апреля 2010 в 14:28

Azerot wrote:
Quote:
во время запроса сайта создается процесс php-cgi, занимающий память 230М

Значит PHP работает в режиме CGI, что не очень производительно, хотя и лучше в плане безопасности.
230M - это как бы очень дохрена. Видимо, действительно, много лишнего. Или, например, очень много элементов какого-либо товарного каталога засасывается, хотя реально столько и не нужно.

Quote:
На сервере установлен eAccelerator, но техподдержка в открытую созналась, что он как надо не настроен

eAccelerator не работает в режиме CGI, либо нужен fastCGI либо mod_php

Посмотрел, другой сайт со скромным набором модулей 170М, что тоже немало. Товарного каталога нет.
По поводу eAccelerator возьму на заметку.

Аватар пользователя axel axel 25 апреля 2010 в 16:25

Azerot wrote:
Quote:
во время запроса сайта создается процесс php-cgi, занимающий память 230М

Значит PHP работает в режиме CGI, что не очень производительно,
Процессы php-cgi могут создаваться и при работе в режиме fastcgi.

Аватар пользователя darkdim darkdim 25 апреля 2010 в 16:55

axel wrote:
Azerot wrote:
Quote:
во время запроса сайта создается процесс php-cgi, занимающий память 230М

Значит PHP работает в режиме CGI, что не очень производительно,
Процессы php-cgi могут создаваться и при работе в режиме fastcgi.

Сто пудов, а как это посмотреть? и еще, мне кажется что Drupal не кеширует странички. В случае с Boost он дописывает внизу страницы информацию о кеше, а с Authcache непонятно как это можно проверить.

Сорри, authcache тоже дописывает info

var authcacheFooter = { "info": { "page_render": 803.08, "cache_render": "-1", "cache_uid": "14", "cache_inc": "cacherouter.inc", "cache_time": 1272199984 }, "ajax": { "q": "homepage/" } };

Аватар пользователя axel axel 25 апреля 2010 в 20:30

darkdim wrote:
Сто пудов, а как это посмотреть?

Перечитал топик ещё раз, Азерот прав - в данном случае это cgi. Если как описано процесс php-cgi создаётся только на время запроса к сайту, а затем пропадает - это cgi. При fastcgi-режиме php-cgi будут постоянно висеть в списке процессов. Собственно вся разница между cgi и fastcgi для PHP в том, что в fastcgi-режиме интерпретатор (возможно в нескольких экземплярах) уже запущен в памяти и ждёт запроса, для cgi старт проиходит каждый раз заново.

Аватар пользователя darkdim darkdim 25 апреля 2010 в 14:54

RxB wrote:
А я уже писал, что техподдержку мы оказываем, но вот вопрос с юр.лицами пока открыт

это я помню, жду совещания по этому вопросу

Аватар пользователя Azerot Azerot 25 апреля 2010 в 16:58

Quote:
Процессы php-cgi могут создаваться и при работе в режиме fastcgi.

Могут, если так написан wrapper для fastCGI.
Посмотреть точно можно в настройках веб-сервера

Аватар пользователя darkdim darkdim 25 апреля 2010 в 17:30

Azerot wrote:
Quote:
Процессы php-cgi могут создаваться и при работе в режиме fastcgi.

Могут, если так написан wrapper для fastCGI.
Посмотреть точно можно в настройках веб-сервера

как это можно сделать через ssh?

Аватар пользователя darkdim darkdim 10 ноября 2015 в 11:46

axel wrote:
darkdim wrote:
как это можно сделать через ssh?

Посмотри просто phpinfo() для начала.

И я об этом подумал.
Там такая строчка:
Server API CGI/FastCGI

Модуль системной информации выдает:
PHP interface cgi-fcgi

Могу еще в isp manager посмотреть. Скрин:

Аватар пользователя darkdim darkdim 25 апреля 2010 в 20:44

RxB wrote:
Врядли, буст кеширует полные страницы

Попробовал Authcache установить только для залогиненных юзеров + Boost(по умолчанию для анонимов).
Пока связка работает нормально. Никаких глюков не вижу, хотя читал что может кеш не сбрасывать.

Аватар пользователя Azerot Azerot 25 апреля 2010 в 19:17

Quote:
как это можно сделать через ssh?

Самое надёжное - найти конфиг апача и посмотреть.
Также можно почитать логи апача - там обычно пишутся записи о старте fastCGI процессов и их завершении.
Также можно посмотреть списки процессов. Если процессы php-cgi продолжают работать по завершении окончания работы скрипта, скорее всего это fastCGI процессы.

Аватар пользователя Xaber@drupal.org Xaber@drupal.org 7 мая 2010 в 17:34

230m - что-то как-то чересчер дохрена. Только правда вопрос сразу - память, приведенная вами, это песочница, или реально съеденная память?

Просто если посмотреть на циферки в топе:
SIZE RES COMMAND
617M 81488K php-cgi

они неоднозначны. Хотелось бы реальной цифры, занимаемой процессом.

+ попытки разгрузить сайт отключением модулей - вопрос тоже интересный. Если не трогать PHP именно, то views - еще та зараза. Сплошные JOIN запросы, от которых волосы дыбом встают. Однако это довольно легко "лечится" через бд.

Мне кажется, что вы зря односторонне рассматриваете ваши проблемы. Как-то было сказано, что PHP - тупой как пробка. Его работу (кстати и проц и вытекающие задержки, висяки и мертвяки) зачастую тормозит база. Очень часто, если она норм не сконфигурирована.

А вообще, сейчас все вокруг тычут в небо пальцем.

Статистика из Devel по памяти довольно адекватная, только если брать во внимание память....сейчас смотрю топ:
33596K 17120K accept 1 0:28 14.99% php-cgi у одного из сайтов. Статистика за 15 минут: 270 анонимов и 83 авторизированных. Из кеширования - только стандартные средства кеширования. Ось 32 бита freebsd 8.
Другой - 626M 92252K sbwait 3 0:54 1.37% php-cgi. Статистика за 15 минут - 167 анонимов и 95 авторизированных. Кеширование - стандарт. На обоих eAccelerator есть. PHP - fastcgi. ось 64 бита тоже FreeBSD 8.

Сделайте:

find / -name my.cnf
cp {путь/my.cnf} ~/
cp {*.ini из phpinfo()} ~/

для начала и было бы замечательно поговорить дальше.

А вообще
"Authcache + Boost работает, но сервер все равно вешается("
За шкирку выбрасывайте организацию, которая не признает nginx. Результаты работы Boost он раздал бы так быстро, что вы не заметили бы. А связка apache - fastcgi - php - извращение. Статику отдавать апачем - извращение (собака, хотя нет, псина.... хм. ПСИНИЩЕ и тут зарыто. Если не оптимизировали, естественно.).

и еще. Как сконфигурирован модуль рекламы? Если не Raw а JS - ждите неприятностей и тут.

Больше говорить в пустую нет смысла.

Аватар пользователя Siegfrid@drupal.org Siegfrid@drupal.org 7 мая 2010 в 17:51

230 метров на php - это не кашерно...

У меня на VPS:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10509 mysql 40 0 183m 72m 4252 S 0 13.9 106:24.17 mysqld
18951 www-data 40 0 84728 52m 20m S 0 9.9 13:24.98 apache2
18952 www-data 40 0 74540 39m 18m S 0 7.6 12:55.38 apache2
18967 www-data 40 0 67404 33m 18m S 0 6.3 13:55.41 apache2
19184 www-data 40 0 67540 32m 18m S 0 6.2 14:20.93 apache2
18953 www-data 40 0 65516 31m 18m S 0 5.9 14:14.21 apache2
18947 root 40 0 57224 9572 5428 S 0 1.8 0:01.22 apache2
3212 root 40 0 8164 2660 2104 S 0 0.5 0:00.09 sshd
2719 postfix 40 0 6088 1632 1484 S 0 0.3 0:02.92 tlsmgr
2565 postfix 40 0 5848 1568 1424 S 0 0.3 0:05.27 qmgr
31509 www-data 40 0 5216 1452 848 S 0 0.3 1:29.05 nginx

конфигурация - nginx + apache + eaccelerator

Про то, как настраивать можно почитать тута

Аватар пользователя darkdim darkdim 9 мая 2010 в 14:14

"<a href="mailto:Xaber@drupal.org">Xaber@drupal.org</a>" wrote:
для начала и было бы замечательно поговорить дальше.

А вообще
"Authcache + Boost работает, но сервер все равно вешается("
За шкирку выбрасывайте организацию, которая не признает nginx. Результаты работы Boost он раздал бы так быстро, что вы не заметили бы. А связка apache - fastcgi - php - извращение. Статику отдавать апачем - извращение (собака, хотя нет, псина.... хм. ПСИНИЩЕ и тут зарыто. Если не оптимизировали, естественно.).

Больше говорить в пустую нет смысла.


PHP работал в cgi, соответственно eAccelerator не работал, проблема решилась приглашением грамотных системщиков.