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

Тормозит сервер

Профилировщик PHP или логи MySQL вас спасут

Со стороны системного администрирование могу сказать что односторене правильный вопрос.

При редактировании, сохранении, удалении ноды действительно может подтормаживать сервер.
Конечно если при редактировании то имеем виду долгое открытие страницы редактирования ноды, или долгие пост запроси по типу (зависимых списков и т.д., т.е. ahah, ajax и прочее).

Вариантов на самом деле несколько:

1. Ваш сайт перегружен модулями, такими как:
редакторы, те же зависимы списки, различные conditional fields, manage forms, node form cols..
которые темизируют, упрощают процесс создания ноды.
Некоторые из которых могут, в том числе, грузить браузер вызываю утечку памяти у javascript handler'a браузера.

2. Ваш сервер либо калькулятор, либо не настроен.

Например я уже убедился что даже для 1 сайта на друпале 2Гигов оперативки и 2Гц проца недостаточно.

Во время активного запроса Дру нагружает Апач вплоть до 80% от номинала и на 700 метров оперативы. Соответственно если на сервере еще что-то выполняется параллельно, типа почтового сервера... Во общем как и сказали нужно смотреть или "больного - Друпал", или "больного - Сервер"

Добавление.

Друпал последнее время это неповоротливый слон. Да что говорить, вы посмотрите как открывается drupal.ru, создание ноды до 10 сек, открытие 5-8 сек.

Это показывает нам эталон работы самого друпала.
Если вы хотите чтобы у вас было быстрее чем друпал.ру и не надейтесь ))

Т.е. вы хотите сказать что у создателей этого сайта проблема с мозгом?

Трудновато привести пример, у меня всего один проект не на друпале, и на одном хосте с друпалом.
Это проект на битриксе.

Соответственно:

Сервак: Pentium 4 2.2, 2Г ОЗУ
Всего 2 сайта, один на дру, второй на битриксе.

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

Все управляеющие ссылки и кнопки в битриксе срабатывают вплоть до того как ты захотел на них нажать (утрировано конечно)
В друпале средняя скорость выполнения 1.5сек - 3.7сек в зависимости от загружаемой страницы,
в битриксе я не нашел такой кнопки, которая заставила бы меня ожидать более 1сек.

У меня сейчас 2 сайта на друпале, один открывается 370мс, второй 980мс (в основном по причине того что он еще в активной разработке и там не сведены js и css)

Но мы же говорим не про открытие нод, а про их создание, а это уже другие цифры 8-10сек, это минимальные показатели при среднем наполнении модулями и типом материала 10-20 полей)

Никто не спорит что оно субъективно Говорю ведь я и только за свой опыт.
Если у вас есть другие цифры прошу их тут привести. Тогда я пойму что у меня где-то еще есть проблемы и займусь их поиском и решением. Я тоже не говорю что я супер-пупер батька в друпале

А дупал.орг это действительно совершено иная цмс, или вы думаете они все свои решения в общий доступ и бесплатно выкладывают

Мне тогда будет очень интересно за счет чего они живут )

У меня херова куча сайтов на друпале и больше 500мс я не наблюдал ещё

RxB

У меня херова куча сайтов на друпале и больше 500мс я не наблюдал ещё

Для чего? Для создания ноды? Для открытия страницы редактирования ноды?
Открытие самой страницы закэшированой, это понятно что не будет превышать 500мс.

А вот с отключенным кэшированием извините, 2-7сек. Таковы цифры друпала на сег день.

Вопрос: к этому сайту вы имеете отношение?

"divined" wrote:

Открытие самой страницы закэшированой, это понятно что не будет превышать 500мс.

Ну давайте тогда и я свои наблюдения буду говорить:

1.
Table_locks_immediate 300499 Количество раз, когда блокировка была нужна немедленно.
Table_locks_waited 371 Количество раз, когда серверу приходилось ожидать блокировку.

2.
Qcache_lowmem_prunes 55372 Количество раз, когда MySQL приходилось удалять запросы из кэша из-за нехватки памяти. В идеале равно нулю.

Соответственно вот те штуки которые у меня вызывают недовольство. Как эти вещи проанализировать более детально.

ПС. для тех кто не знает, анализ SQL у дру находится по адресу: admin/reports/status/sql

Посмотрел активные запросы к базе.

Около 50+ запросов в состоянии Locked:
/* ????? : db_query */ SELECT COUNT(*) FROM (SELECT node_data_field_exhimage.field_exhimage_fid

ну и дальше не видно...
Как узнать где вызывается этот запрос?

Кильнул все процессы, теперь:
| 4121 | | localhost | | Query | 128 | Sending data | /* ????? : locale */ SELECT s.source, t.translation, t.language FROM locales_source s LEFT JOIN |
| 4136 | | localhost | | Query | 87 | Sending data | /* ????? : locale */ SELECT s.source, t.translation, t.language FROM locales_source s LEFT JOIN |

Не выполняются эти запросы, т.е. долго выполняются 128 сек это перебор, вам не кажется )))
Причем активных всего этих два запроса.

Не было ли апдейта с пятёрки?

Нет.

Кстати я увидел тут http://www.drupal.ru/node/28481 подобную проблему.

Только у меня 6-ка. Вот сижу ищу, где я объявлял переменные языка через global.

Вот еще:
45.62 мс
cache_get
SELECT data, created, headers, expire, serialized FROM cache_menu WHERE cid = 'links:navigation:tree-data:40a57ccbaa85c3f039b6448ca5c3c3d8'

Вот такой запрос из друпала выплняется 45мс, напрямую из консоли 1.4мс, кэшированный 0.3мс
Каковы причины различия?

Да и вообще почему выполняются запросы cache_get, cache_set при отключенном кэшировании?

Так же мне интересно:

Главная страница генерирует 480+ запросов к БД, 80% из которых запросы i18nstrings_get_string.

3976.75
_locale_rebuild_js
SELECT s.lid, s.source, t.plid, t.plural, t.translation FROM locales_source s LEFT JOIN locales_target t ON s.lid = t.lid AND t.language = 'ru' WHERE s.location LIKE '%.js%' AND s.textgroup = 'default' ORDER BY t.plural DESC

Этот запрос вообще выполняется 4сек, я в шоке. Куда посоветуете смотреть дальше?

Смотрел какие запросы чаще всего идут в базу параллельно для перевода таблицы в InnoDB.
Увидел что это в основном cache_menu и cache_form. Но перевести их в InnoDB не даст прироста производительности, т.к.

cache_form 1Гиг, cache_menu 0.5Гиг

Перевод их в InnoDB потребует от меня перенастроить mysql на использование буфера в 2Гиг, а это вся моя оперативка. Меньшее число буфера не даст эффективности InnoDB.

Вопрос: Эти таблицы должны быть такими огромными? Можно их отчистить вообще? Почему друпал при нажати кнопки отчистить все кэши их не чистит?

И mysqltuner сообщает: Joins performed without indexes: 907

Как узнать какие запросы объединяют таблицы без индексов, да и какие таблицы

Полное отключение кэша друпал для меня дало увеличение производительности в 20 раз.
Т.е. раньше форма создания ноды занимала 700+ запросов, которые выполнялись за 4-5сек, после отключения - 200-300мс. Основным источником задержки были функции cache_get и cache_set, которые выполнялись по 2 раза для каждого типа содержимого и занимали до 400мс каждый.

Отключил след образом: в файле cache.inc в начале функций cache_get и cache_set вставил:

Конечно я думаю что виноват не друпал, а какой-то из модулей (грешу на nodehierarchy), который и заставляет запросы из этих функций выполнятся неправильно и с большим объемом данных.
Примерный результат запроса весил от 2 до 3Мб. И таких запросов при создании ноды было 10+.

Кстати, отключение модуля locale уменьшает количество завпрос с 700 до 200, и дает прирост производительности в 200 раз.

"divined" wrote:

Кстати, отключение модуля locale уменьшает количество завпрос с 700 до 200, и дает прирост производительности в 200 раз.

на вашем херовом хостинге(сервере), сделайте поправку...

какую? mysql оптимизирован. mysqltuner по всем пунктам пишет ОК
Скорость запросов с консоли, да и все нагрузочные тесты sysbench показывают отличные результаты.

Сервер вроде настроен отлично, опять же хотелось повторить что Битрикс на нем работает на ура. Время генерации админки битрикса не превышает 800мс. Время создания материала в инфоблоке не превышает 1сек.

Так же стоит nginx который отдает статику, а пхп отправляет апачу. Анонимам страница отдается за 400-700мс.
Скорость переходов по страницам админки, тоже приемлемая: 0.5-2сек. (Друпал)

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

Теперь бы хотелось вылечить от 100 кратных запросов модуля locale и i18n. А также найти причину огромных размеров таблиц кэша и больших объемов кэшируемых данных.
Посоветуйте плиз куда копать.

Я в другом топике предлагал меряться письками скоростью выполнения запросов.
У вас криво настроен сервер, либо в силу убогости и/или убитости железяки из неё больше не вытянуть

Давайте лучше померяемся размерами запрса cache_get,

длина запроса у меня 2.8Мб текстовой информации.
Т.е. тело запроса по длине больше романа "Война и Мир".

Так же померяемся размерами таблицы cache_form, которая весит у меня 1Гиг.

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

давайте вашу базу или мне самому демо-данные придумывать?

хмм, все 2гига? Или что-то конкретное?