Как оптимизировать Друпал, чтобы решить вопрос с недостатком памяти, выделенной на php?

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

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 4 января 2009 в 23:14

Добрый день, уважаемые коллеги!

Столкнулся с очередным вопросом, ответить на который я по причине недостатка знаний пока не могу. В разработке имеется сайт, который крутится на хостинге с рядом скачанных с drupal.org чужих и парой простеньких (если не сказать примитивных), написанных мной модулей. Кэширование отключено. Установлены, в частности, cck, views и devel (больше тяжёлых модулей нет). PHP limit жёстко выставлен хостером на 64 метра (изначально вообще было 16). С помощью devel'а стараюсь отслеживать то, как работает сайт на различных страницах. Обычно на выходе страницы devel указывает на 28 метров израсходованной памяти, но при загрузке admin/modules показатель вырастает до 45, что не может не настораживать. Доходит до того, что я не могу поставить drupal_for_firebug, чтобы с его помощью исправлять ошибки и свои ляпы, потому что вылезают ошибки о перерасходе памяти. Такими темпами я почти уверен, что мне не хватит памяти на token, pathauto, acm/tal и advanced forum, а также пару модулей, которые мне придётся писать самому.

Подскажите, это у меня руки не из того места растут или всё так и должно быть? Если это как-то можно скорректировать/оптимизировать (увеличение лимита до 96 метров, к сожалению, не предлагать), то не подскажите ли как? Помыкался по форуму и даже по русскоязычному Друпал-поиску, но ответа на этот вопрос не нашёл -(

Спасибо заранее.

Комментарии

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 5 января 2009 в 1:14

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

Аватар пользователя nleo nleo 5 января 2009 в 1:16

сменить хостера

установить еакселератор. у меня по показанием девела расходоволась около 10 метров("тяжелых" модулей нет вообще). после долгой переписки с хостером, мне поставили акселератор, за что огромное спасибо. Расход стал 2-3 метра. Выполнение ускорилось с 5-10 секунд до 300мс-2с.

Аватар пользователя Geldora Geldora 5 января 2009 в 10:26

Но вообще тема поднята интересная!

Если нет еакселератора? Если хостер его не собирается ставить, а менять проверенное шило на неизвестное мыло не хочется?

Какие еще существуют способы оптимизации именно по пхп_мемори_лимит?

Я недавно в книжном нашла книжку ПроДрупал 5 (которую писали лулабот и Дрис Байтаерт), там был раздел об оптимизации. Можно как-то что-то поправить в сеттинг.пхп, еще какие-то вещи настроить - причем, не очень сложные!!! У кого есть эта книжка, или кто знает еще такие тонкости - напишите их тут, пож-ста!
______
Столкнулась с этой проблемой осенью, менять хостера - собственно не на кого, сайт казахский и местный хостер соответственно. Еакселератор ставить они не захотели, после переговоров увеличили лимит на память пхп, но, как говорится, осадочек остался...

Аватар пользователя Valeratal Valeratal 5 января 2009 в 11:14

Гелдора, тема то интересная, но друпал не для шаред хостингов. По крайне мере с большим количеством модулей
Мне например не хватало и 80, когда я пытался открыть таблицу с данными 300 человек созданную модулем webform
Поэтому, оптимально иметь VPS или лучше

Аватар пользователя Ильич Рамирес Санчес Ильич Рамирес Санчес 5 января 2009 в 12:32

"<a href="mailto:ingumsky@drupal.org">ingumsky@drupal.org</a>" wrote:
PHP limit жёстко выставлен хостером на 64 метра (изначально вообще было 16)

о боже.
модулей сколько?

блин. этож тоже cgi приложение по сути... по 60 метров на процесс. много

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 5 января 2009 в 13:22

Geldora
Единственная книжка про Друпал, которую я знаю, это Pro Drupal Development, но Дрис там написал только предисловие. А вообще посмотрю, что там про оптимизацию написано — я ещё не дочитал до этой главы.

Valeratal
Вы, наверное, правы, но как-то смысл удобства и расширяемости Друпала теряется, если он уже на малых оборотах так сильно теряет в скорости — увеличивать php limit можно хоть до бесконечности, но это быстродействия системе не придаст, разве что от ошибок недостатка памяти избавит. В конечном итоге, он ведь в базовых случаях и не делает ничего сверхъестественного, а память жрёт, «как взрослый». Да и у меня пока нет ни нагрузки, ни бешеного числа модулей, а проблемы с недостатком памяти уже есть.

Ilya1st
Назову по группам по алфавиту: admin_menu, cck (+filefield+imagefield), «дополнительные» модули ядра (отключены только blog, blog api, content translation, open id, syslog, throttle), date (включено всё), devel (включён только сам devel), imageapi (+imageapi gd2), bbcode, самописный onthisday, simple menu. Вчера отключил advanced help в надежде на то, что это даст хотя бы минимальный прирост в скорости — не помогло.

Аватар пользователя kodo kodo 5 января 2009 в 14:24

Фух... посмотрел 128 Мб... аж полегчало... а то такие ужасы говорят...
Но об оптимизации всегда надо думать, а то модулей наставил до чертиков, пока все вертится, хоть и не скажу что летает, но живет, да и чего ему не жить, если из пользователей практически только я любимый. Smile

Аватар пользователя gor gor 5 января 2009 в 18:19

Проблема в том, что модули многие пишут не совсем оптимальными.
Это опенсурс. И не всегда у человека, что пишет модуль - хватает квалификации.
Вот и получается что напакованый модулями друпал начинает тормозить.
Сугубо личное мнение.

Аватар пользователя Geldora Geldora 5 января 2009 в 18:20

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

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

Например Wink

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

Говорят, не стоит использовать пхп в блоках, либо нужно использовать блок кэш.

Поможет ли использование модуля буст в подобных ситуациях?

Кстати, в друпал про был совет внести изменения в сеттингс.пхп, что-то там уменьшить-увеличить. Если у кого есть эта книжка - выложите этот отрывок!? (Я читала на стойке в книжном Wink

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 6 января 2009 в 2:30

"gor" wrote:
Проблема в том, что модули многие пишут не совсем оптимальными.
Это опенсурс. И не всегда у человека, что пишет модуль - хватает квалификации.
Вот и получается что напакованый модулями друпал начинает тормозить.
Сугубо личное мнение.

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

Geldora
Ингумский Wink

С модулями постараюсь разобраться, но проблема в том, что большинство из них мне нужно, пусть и не на полную мощность. Я готов отказаться от cck, например, и создавать в дальнейшем типы контента при помощи своих модулей (хотя я пока не понял, как реализовать с помощью своего модуля все те примочки типа виджетов и проч.). Вот и получается, что приходится тащить за собой кучу модулей, функционал которых используется мной только на 30 процентов.

Что касается, блок-кэша — видимо, этот камень как раз подойдёт к моему огороду — пхп в блоках у меня используется, а вот кэшировать его там я пока не научился, ибо пишу блоки, ориентируясь на сниппеты сетегнома/друпал.ру/друпал.орг и примеры из книжки про Друпал.

Про модуль boost пока не слышал — надо почитать.

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

Если я отключу update status, как я смогу убедиться в том, что есть обновления ядра и модулей? Или www.example.net/admin/reports/updates/check всё-таки спасёт отца русской демократии?

PS И специально по просьбе Geldora выкладываю фрагмент главы из книжки, посвящённый оптимизации с использованием settings.php, к которому хотел бы присовокупить слова благодарности — спасибо Вам:

Quote:
Pruning the Sessions Table
Drupal stores user sessions in its database rather than in files (see Chapter 16). This makes
Drupal easier to set up across multiple machines, but it also adds overhead to the database for
managing each user’s session information. If a site is getting tens of thousands of visitors a
day, it’s easy to see how quickly this table can become very large.
PHP gives you control over how often it should prune old session entries. Drupal has
exposed this configuration in its settings.php file.
ini_set('session.gc_maxlifetime', 200000); // 55 hours (in seconds)
The default setting for the garbage collection system to run is a little over two days.
This means that if a user doesn’t log in for two days, their session will be removed. If your
sessions table is growing unwieldy, you’ll want to increase the frequency of PHP’s session
garbage collection.
ini_set('session.gc_maxlifetime', 86400); // 24 hours (in seconds)
ini_set('session.cache_expire', 1440); // 24 hours (in minutes)
When adjusting session.gc_maxlifetime, it also makes sense to use the same value for
session.cache_expire, which controls the time to live for cached session pages. Note that
the session.cache_expire value is in minutes.
Managing the Traffic of Authenticated Users
Since Drupal can serve cached pages to anonymous users, and anonymous users don’t nor-
mally require the interactive components of Drupal, you may want to reduce the length of
time users stay logged in or, crazier yet, log them out after they close their browser windows.
This is done by adjusting the cookie lifetime within the settings.php file. In the following line,
we change the value to 24 hours:
ini_set('session.cookie_lifetime', 86400); // 24 hours (in seconds)
And here we log users out when they close the browser:
ini_set('session.cookie_lifetime', 0); // When they close the browser.
The default value in settings.php (2,000,000 seconds) allows a user to stay logged in for
just over three weeks (provided session garbage collection hasn’t removed their session row
from the sessions database).

Аватар пользователя nleo nleo 6 января 2009 в 2:44

"<a href="mailto:ingumsky@drupal.org">ingumsky@drupal.org</a>" wrote:
Что касается, блок-кэша — видимо, этот камень как раз подойдёт к моему огороду — пхп в блоках у меня используется, а вот кэшировать его там я пока не научился, ибо пишу блоки, ориентируясь на сниппеты сетегнома/друпал.ру/друпал.орг и примеры из книжки про Друпал.

создать свой модуль навать его мои_блоки и пихать туда сниппеты, там и управлять кешированием блока
http://api.drupal.org/api/function/hook_block/6

BLOCK_CACHE_PER_ROLE (default): The block can change depending on the roles the user viewing the page belongs to.
BLOCK_CACHE_PER_USER: The block can change depending on the user viewing the page. This setting can be resource-consuming for sites with large number of users, and should only be used when BLOCK_CACHE_PER_ROLE is not sufficient.
BLOCK_CACHE_PER_PAGE: The block can change depending on the page being viewed.
BLOCK_CACHE_GLOBAL: The block is the same for every user on every page where it is visible.
BLOCK_NO_CACHE: The block should not get cached

"<a href="mailto:ingumsky@drupal.org">ingumsky@drupal.org</a>" wrote:
Если я отключу update status

он помоему только на админку влияет

вообще, как я понимаю ситуацию есть два варианта:
1) Наращивание мощности сервера(сменить хостера) и использование различных систем кеширования кода и данных
2) Отказ от модулей в пользу своих оптимизированных и написанных под конкретные нужды. Сюдаже можно отнести хаканье и оптимизацию ядра под свои нужды, это уже крайний вариант, когда надо задуматься о свой КМС под свой проект.

А так все что можно было сделать для ускорения в ядре и сеттингс.пхп уже сделано. И других вариантов нет. Нет в сеттингс.пхп настройки "Использовать памяти 16 мб и выполнятся менее 300 мс", ну никак нету

Аватар пользователя Valeratal Valeratal 6 января 2009 в 10:20

в приведенном отрывке предлагают уменьшить время сессии?
а сессия считается только для зарегенных или для гостей также?

Просто у меня таблица сессионс действительно разрастается
а если чищу - то пользователи негодуют (стоит модуль remember me - и обычно люди запоминают себя:) )

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 8 января 2009 в 22:48

Хм... Включил в Devel отображение запросов к базе, использованных при загрузке страницы и... просто офигел. Вот, например, чем начинается вывод списка запросов при обращении к www.example.net/admin/settings/language:

Quote:
Executed 235 queries in 154.61 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 1574.98 ms.

Сижу, ломаю голову, размышляя над тем, как это оптимизировать. Большая часть запросов используется по одному разу, а значит мне ничего не даст кэширование их вывода через variable_set, например. Тем не менее, бóльшая часть запросов лезет из одних и тех же функций и, соответственно, модулей. Так, locale вызывается сорок раз с разным условием WHERE, а drupal_lookup_path... 128 раз! Я просто обалдел. Дорогие товарищи, можно ли с этим что-нибудь поделать? Это же полнейшее безобразие -(

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 9 января 2009 в 2:00

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

Аватар пользователя Geldora Geldora 12 января 2009 в 12:12

Хм, посмотрите в Книгах старый-престарый пост Акселя как увеличить производительность. Там есть совет отказаться от локализованной версии и от алиасов путей Wink

Есть какие-то патчи, которые уменьшают проблему, их тоже можно поискать.

Спасибо за отрывок из книги Smile

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 12 января 2009 в 16:35

Если бы сайт юзал только я, я бы мог отказаться от локализации, но сайт рассчитан как раз на русскоязычного пользователя, которому сложно получать информацию на английскому языке.

Спасибо, «будем искааать...» (с) -)

На здоровье! Wink

Аватар пользователя Химический Али Химический Али 12 января 2009 в 16:50

А что будет, если заменить по коду вызовы вида t('english') на 'русский'? Сильно производительность увеличится? Smile

Или переписать функцию t() так, чтобы она по ассоциативному массиву возвращала значения? Smile Хотя, массив, наверное, массивыный выйдет Smile

Аватар пользователя rusec rusec 14 января 2009 в 0:58

Химический Али wrote:
Или переписать функцию t() так, чтобы она по ассоциативному массиву возвращала значения? Smile Хотя, массив, наверное, массивыный выйдет :)

А зачем переписывать?
Она умеет.
См. $conf['locale_custom_strings_ru'] в конце settings.php

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 12 января 2009 в 17:09

"Химический Али" wrote:
А что будет, если заменить по коду вызовы вида t('english') на 'русский'? Сильно производительность увеличится? Smile

Это придётся в модули ядра лезть и править там, что не кошерно.
"Химический Али" wrote:
Или переписать функцию t() так, чтобы она по ассоциативному массиву возвращала значения? Smile Хотя, массив, наверное, массивыный выйдет :)

По идее, это было бы правильнее. Мне кажется, с таким массивом работать было бы быстрее и удобнее, чем сорок раз на страницу вызывать locale c разными условиями.

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 13 января 2009 в 12:36

От автоматизации «кошерность» больше не станет -) Вообще это недоделка разработчиков, отталкивавшихся от того, что английский всех устроит -( Надеюсь, в семёрке будет учтён этот факт.

Аватар пользователя EllECTRONC EllECTRONC 10 апреля 2009 в 22:14

Когда ж вы научитесь пользоваться гуглом — Книга «Pro Drupal Development, Second Edition», начиная со стр 527, глава 22 (про оптимизацию), некоторых страниц нет.
+ на drupal.org есть аж 3 способа по увеличению php_memory_limit, сама недавно воспользовалась и «обзавелась» своим php.ini.


Drupal Search — поиск по 6 сайтам