20% и более ускорение в друпал 7

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

Аватар пользователя gorr gorr 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 и т.д.

Комментарии

Аватар пользователя Stutzer Stutzer 18 марта 2009 в 21:19

Valeratal wrote:
итого год
как раз начнем из кризиса выходить Smile (надеюсь)

Есть мнение, что кризис ещё и не начинался, а затянется все лет на 7-10.
Правда, я оптимист? Smile

Аватар пользователя BMW BMW 18 марта 2009 в 17:50

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

Аватар пользователя sas@drupal.org sas@drupal.org 18 марта 2009 в 12:21

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

Аватар пользователя Valeratal Valeratal 18 марта 2009 в 12:27

мне вот что интересно
Есть модуль трекер2, который вроде лучше работает чем стандартный
и ! стоит на друпал орг
Почему стандартный не заменили на новый, по умолчанию

Аватар пользователя dfaker dfaker 19 марта 2009 в 17:09

Судя по тесту 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) кое какая подборка статей по оптимизации скорости друпала

Аватар пользователя botan botan 20 марта 2009 в 13:09

Ставил недавно транк семерки .. включил девел и наблюдал ..

Главная страница 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

Да, конечно, следующее не может не радовать:

1.53 1 node_load_multiple

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 drupal_lookup_path SELECT dst FROM url_alias WHERE src = :src AND language IN(:language, '') ORDER BY language DESC

0.12 * 94 = 11.28 Sad

Apache Benchmar с самого на себя:

Server Software:        Apache/2.2.9
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 Software:        Apache/2.2.9
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)

Это конечно просто мега модно, но с кешированием тоже есть свои нюансы неприятные Sad
Очень нравится друпал, но производительность это очень неприятный фактор.
На любом говнохостинге заказчика он работает будто его за хвост держат .. а до этого сайт с html страничками у заказчика открывался мнговенно .. и потом сиди и доказывай что ты не верблюд и почему нужно для нашего мега модного и суперского сайта новый хостинг и почему он должен платить больше денег в месяц.

Аватар пользователя munkie munkie 31 марта 2009 в 19:17

Мы на нашем проекте brandz.ru, сделали функцию для загрузки нескольких нод:
node_load_range(), которая в свою очередь запускает хук nodeapi:load_range в который передает массив полученных нод.

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

При обычном node_load() 20 нод и 10 модулях, которые к этим нодам что-то добавляют, получим:
20 + (20 * 10) = 220 запросов
При node_load_rang() - 1 + 10 = 11 запросов

Аватар пользователя penexe penexe 31 марта 2009 в 19:56

"munkie" wrote:
Мы на нашем проекте brandz.ru, сделали функцию для загрузки нескольких нод:
node_load_range(), которая в свою очередь запускает хук nodeapi:load_range в который передает массив полученных нод.

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

При обычном node_load() 20 нод и 10 модулях, которые к этим нодам что-то добавляют, получим:
20 + (20 * 10) = 220 запросов
При node_load_rang() - 1 + 10 = 11 запросов


хороший проект кстати

Аватар пользователя munkie munkie 31 марта 2009 в 20:30

penexe wrote:
"munkie" wrote:
Мы на нашем проекте brandz.ru, сделали функцию для загрузки нескольких нод:
node_load_range(), которая в свою очередь запускает хук nodeapi:load_range в который передает массив полученных нод.

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

При обычном node_load() 20 нод и 10 модулях, которые к этим нодам что-то добавляют, получим:
20 + (20 * 10) = 220 запросов
При node_load_rang() - 1 + 10 = 11 запросов


хороший проект кстати

Давно хотел написать статью (или серию статей) о том как и что мы сделали, но руки никак не доходят ).