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

Спасибо. А поподробнее не расскажете, что это акселератор? Может и мой хостер сможет такую штуку для меня поставить.

Спасибо. Буду общаться с хостером на эту тему.

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 в надежде на то, что это даст хотя бы минимальный прирост в скорости — не помогло.

"gor" wrote:

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

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

Geldora
Ингумский

С модулями постараюсь разобраться, но проблема в том, что большинство из них мне нужно, пусть и не на полную мощность. Я готов отказаться от 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).

Valeratal
Там есть подзаголовок перед рассказом о сессиях.

Quote:

Managing the Traffic of Authenticated Users

Хм... Включил в 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 раз! Я просто обалдел. Дорогие товарищи, можно ли с этим что-нибудь поделать? Это же полнейшее безобразие -(

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

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

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

На здоровье!

"Химический Али" wrote:

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

Это придётся в модули ядра лезть и править там, что не кошерно.

"Химический Али" wrote:

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

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

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