Кешування завантажувального пристрою Drupal

Мені цікаво, чи хтось зробив спроби "кешувати" процес завантаження в Drupal.

Як правило, Drupal запускатиме 7 фаз завантаження на кожному запиті, але, можливо, у розгорнутій виробничій системі можна було б покінчити з деяким чи всім цим?

Можливі пропозиції, які я маю на увазі, можуть бути

1. Серіалізація завантаженого стану та вклеювання його в мембраш
2. Сценарій може створити патч для bootstrap.inc, який буде жорстко кодувати певну інформацію у файл.
3. Я вважаю, що Девід Стросс намагався утримати завантажений друпал на лівенті.
4. Інші божевілля?

Які спроби існують, а які, як відомо, є (дещо) надійними?

PHP - це архітектура, що не має спільного доступу. Це має свої переваги та недоліки.

Одним недоліком є ​​те, що зробити щось подібне непросто. Існує не так багато стану, яке можна десь зберігати.

Я зробив кілька швидких тестів, і коли увійшов у систему, тоді, здається, завантаження займає близько 17% від загального часу і більше 50%, що фактично завантажує всі файли .module та .inc. Це не те, що можна зберігати в пам’яті. Крім того, це не має великого значення, якщо я використовую memcache або кеш бази даних.

Я намагався отримати деякі результати, коли ввімкнено кеш сторінки, але, здається, Xhprof не повертає надійних результатів; вся справа просто здається занадто швидкою. Але навіть тоді найбільша частина полягає у виконанні гачків init / exit та завантаження файлів, схоже. Я знайшов там цікаву проблему: схоже, що Модуль користувача серйозно сповільнює відповідь кешованої сторінки, оскільки він запускає реєстр через контролер сутності у файлі .module.

З цього приводу Девід Строс показав експериментальну роботу в Копенгагені, де він створив знімок пам’яті після завантаження, а потім повернувся до того, коли сторінку було розміщено. Він використовував Drupal 6 для цього. Переглянувши цифри вище, я думаю, що підвищення продуктивності від цього в Drupal 7 буде зовсім меншим. Однією з причин цього є те, що підключення до бази даних ледаче завантажене (І ви можете отримати досить далеко в завантажувальному інструменті, використовуючи, наприклад, Memcache, перш ніж вам потрібно буде виконати перший запит), і є багато кешованого.

Що дійсно погано в Drupal 7, це шар візуалізації з цими величезними масивами та нескінченними рекурсіями та циклами. Це майже скасовує всю роботу над виконанням, яка потрапила в Drupal 7. Давайте подивимось, як це виглядає в Drupal 8, якщо Twig зробить його основним.

Нарешті, про згадані переваги. Однією з великих переваг є те, що витік пам'яті є неактуальним, оскільки все звільняється після кожного запиту. Я бачив багато програм Java, де використання пам'яті постійно збільшується і потребують регулярних перезавантажень.

Ні, саме Девід Стросс експериментував з карго-подією (тепер називається Кельнер) на https://code.launchpad.net/~fourkitchens/pressflow/6-evented, але я сумніваюся, що з цього вийшло щось серйозне.

Drupal 7 робить є багато бутстрапа вже в кеші, є cache_bootstrapящик для цього. Можна вклеїти його в запам’ятовується.

Ви можете перейти за борт і зменшити завантаження коду, перемістивши частину / багато коду Drupal в C. Дамієн і dhthwy створили розширення PHP за адресою http://drupal.org/project/drupal_php_ext, з цим багато не робиться. Або робити хіпхоп. Я не знаю сучасного стану hiphop & Drupal 7.

Зрештою, вам потрібно уважно ознайомитися з інженерними витратами, скажімо, налагодити роботу хіп-хопу з Drupal 7 (та всім внеском!) Та порівняти це з орендою ще кількох серверів. Якщо ви можете заощадити, скажімо, 5% своїх серверів і у вас 100 000 серверів, продовжуйте це, але ви Facebook? Будьте уважні та економні з оптимізаціями.

На зустрічі High Performance Drupal побачили цікаву презентацію про doh (динамічний обробник об’єктів) . Коротше кажучи, він говорить про швидке завантаження drupal, використовуючи його. Отримує цікавість біля позначки 15:30. Автозагри на стероїдах в короткому з runkit функціонально , а також. QA о 33:00.