17 марта 2009 в 19:57
Натолкнулся на друпал.орг не интересную тему про разработку 7 версии. А именно http://drupal.org/node/324313 . Кратко опишу, что там обсуждали и к чему пришли. В 7-ке будут добавлены функции для множественной загрузки сразу нескольких нодов одним запросом в базу, а также и нескольких термов, нескольких нодов из кеша вместо того, чтобы доставать каждый нод по-отдельности, как делается сейчас, что при использовании стандартных модулей друпала показывает прирост производительности в 20-40% на страницах со списками нодов (главной, страниц таксономии,...),при правильном использовании API 7 друпала сторонними модулями прирост производительности на страницах где подгружаются не отдельные ноды, а списки будет еще существеннее, если модули подгружают свои данные к нодам либо термам. Прирост скорости достигается снижением количества запросов к базе на таких сложных страницах. Новые функции будут называться node_load_multiple(), taxonomy_term_load_multiple(), возможно также будут добавлены user_load_multiple и т.д.
Комментарии
а еще есть кеш для функций модулей, ускоряет загрузку хуков и тд
таблицы registry, registry_file, cache_registry
круто! когда ждать 7-ку?
~6 мес
Ага и ещё ~6 мес пока под неё популярные модули портируют. Но прогресс радует.
итого год
(надеюсь)
как раз начнем из кризиса выходить
Есть мнение, что кризис ещё и не начинался, а затянется все лет на 7-10.
Правда, я оптимист?
Функционал, который напрашивался, на мой взгляд, достаточно давно.
Другой вопрос, как это будет реализовано в модулях и на сколько часто будет применяться.
На мой взгляд это еще один "кирпичик" в сторону "гибкости", для "настройки" соотношения "скорость работы - требования к ресурсам".
мне вот что интересно
Есть модуль трекер2, который вроде лучше работает чем стандартный
и ! стоит на друпал орг
Почему стандартный не заменили на новый, по умолчанию
А во всех ли он местах работает лучше и стабильнее чем стандартный?
BMW: по приведенной ссылке патч, который одобрен есть, можно посмотреть как реализовано
Я имел в виду как это будет в модулях использоваться. (:
Ждать 7-ки с модулями - минимум 1 год. А ведь потом будет 8-ка в стадии альфы уже. Так что юзайте 6-ку )
ну как раз, не раньше ближайшего НГ
Судя по тесту Performance benchmarking of Drupal 5.12, Drupal 6.6, and Drupal 7.x: we are getting slower ... +20% к скорости ему не помогут даже догнать 6-ю версию, а 5-ю тем более. Тут http://2bits.com/articles/drupal-performance-tuning-and-optimization-for... (ссылка отсюда http://groups.drupal.org/node/15663) кое какая подборка статей по оптимизации скорости друпала
Ставил недавно транк семерки .. включил девел и наблюдал ..
Главная страница 30 нод:
Так сказать "Холодный пуск":
Executed 270 queries in 343.31 milliseconds.
Повторная загрузка:
Executed 271 queries in 43.06 milliseconds.
Причем сервер локальный, который в основном как шлюз используется и площадка для разработки ну и работает VirtualBox под который выделено 2гб памяти.
Version: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
Max Speed: 3800 MHz
Current Speed: 2600 MHz
Memory Device Size: 2 x 2048 MB
Да, конечно, следующее не может не радовать:
SELECT r.nid AS nid, r.vid AS vid, n.type AS type, n.language AS language, r.title AS title,
r.uid AS uid, n.status AS status, n.created AS created,
n.changed AS changed, n.comment AS comment, n.promote AS promote, n.moderate AS moderate,
n.sticky AS sticky, n.tnid AS tnid, n.translate AS translate, r.timestamp AS revision_timestamp, r.body AS body, r.teaser AS teaser,
r.log AS log, r.timestamp AS timestamp, r.format AS format, u.name AS name, u.picture AS picture, u.data AS data
FROM node n INNER JOIN node_revision r ON r.vid = n.vid INNER JOIN users u ON u.uid = n.uid
WHERE (n.nid IN (:db_condition_placeholder_6, :db_condition_placeholder_7, :db_condition_placeholder_8, :db_condition_placeholder_9,
:db_condition_placeholder_10, :db_condition_placeholder_11, :db_condition_placeholder_12, :db_condition_placeholder_13,
:db_condition_placeholder_14, :db_condition_placeholder_15, :db_condition_placeholder_16, :db_condition_placeholder_17,
:db_condition_placeholder_18, :db_condition_placeholder_19, :db_condition_placeholder_20, :db_condition_placeholder_21,
:db_condition_placeholder_22, :db_condition_placeholder_23, :db_condition_placeholder_24, :db_condition_placeholder_25,
:db_condition_placeholder_26, :db_condition_placeholder_27, :db_condition_placeholder_28, :db_condition_placeholder_29,
:db_condition_placeholder_30, :db_condition_placeholder_31, :db_condition_placeholder_32, :db_condition_placeholder_33,
:db_condition_placeholder_34, :db_condition_placeholder_35))
Но как всегда убивает другое:
0.12 * 94 = 11.28
Apache Benchmar с самого на себя:
Server Hostname: ******
Server Port: 80
Document Path: /
Document Length: 93189 bytes
Concurrency Level: 50
Time taken for tests: 190.750 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 93913000 bytes
HTML transferred: 93189000 bytes
Requests per second: 5.24 [#/sec] (mean)
Time per request: 9537.494 [ms] (mean)
Time per request: 190.750 [ms] (mean, across all concurrent requests)
Transfer rate: 480.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 2.3 0 12
Processing: 1451 9453 1550.8 9423 16865
Waiting: 1314 8616 1452.7 8558 15934
Total: 1453 9454 1550.8 9424 16865
Percentage of the requests served within a certain time (ms)
50% 9424
66% 9587
75% 9685
80% 9758
90% 10203
95% 11381
98% 14643
99% 15426
100% 16865 (longest request)
При этом CPU сервака было под 90-99% и mysql надрывался от такого количества конкуренси
Включил Агрессивное кеширование и остальной кеш.
Server Hostname: *******
Server Port: 80
Document Path: /
Document Length: 92721 bytes
Concurrency Level: 50
Time taken for tests: 8.293 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 93272000 bytes
HTML transferred: 92721000 bytes
Requests per second: 120.59 [#/sec] (mean)
Time per request: 414.632 [ms] (mean)
Time per request: 8.293 [ms] (mean, across all concurrent requests)
Transfer rate: 10983.94 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 3 11.6 0 79
Processing: 48 407 83.3 402 789
Waiting: 34 401 86.4 396 773
Total: 60 411 79.2 404 789
Percentage of the requests served within a certain time (ms)
50% 404
66% 431
75% 451
80% 462
90% 501
95% 546
98% 592
99% 646
100% 789 (longest request)
Это конечно просто мега модно, но с кешированием тоже есть свои нюансы неприятные
Очень нравится друпал, но производительность это очень неприятный фактор.
На любом говнохостинге заказчика он работает будто его за хвост держат .. а до этого сайт с html страничками у заказчика открывался мнговенно .. и потом сиди и доказывай что ты не верблюд и почему нужно для нашего мега модного и суперского сайта новый хостинг и почему он должен платить больше денег в месяц.
А также же порадовали: http://api.drupal.org/api/function/module_hook/7 и http://api.drupal.org/api/function/drupal_function_exists/7 соответственно.
Мне есть небольшой повод возгордится. Кусочек моего кода попал в ядро системы.
http://api.drupal.org/api/function/drupal_function_exists/7
Писал об этом на орге в феврале http://drupal.org/node/374145
Мы на нашем проекте brandz.ru, сделали функцию для загрузки нескольких нод:
node_load_range(), которая в свою очередь запускает хук nodeapi:load_range в который передает массив полученных нод.
Базовые модули это конечно не ускорило, но в наших модулях прирост очеведен (особенно в купе с мемкеш кешированием).
При обычном node_load() 20 нод и 10 модулях, которые к этим нодам что-то добавляют, получим:
20 + (20 * 10) = 220 запросов
При node_load_rang() - 1 + 10 = 11 запросов
хороший проект кстати
Давно хотел написать статью (или серию статей) о том как и что мы сделали, но руки никак не доходят ).