Кэширование бутстрапа Drupal

Мне любопытно, пытались ли кто-нибудь "кэшировать" процесс начальной загрузки в Drupal.

Обычно Drupal запускает 7 этапов начальной загрузки при каждом запросе, но, возможно, в развернутой производственной системе можно было бы «покончить» с некоторыми или всеми из них?

Возможные предложения, которые я имею в виду, могут быть

1. Сериализация загруженного состояния и вставка его в memcache
2. Скрипт может сгенерировать патч для bootstrap.inc, который жестко закодирует определенную информацию в файл.
3. Я верю, что Дэвид Штраус пытался поддерживать загрузочную версию Drupal на libevent.
4. Другое сумасшествие?

Какие есть попытки, и которые, как известно, (несколько) надежны?

PHP - это архитектура без общего доступа. Это имеет свои преимущества и недостатки.

Один недостаток заключается в том, что сделать что-то подобное нелегко. Существует не так много состояния, которое может храниться где-то.

Я провел несколько быстрых тестов, и когда я вошел в систему, то boostrap, похоже, занимает около ~ 17% от общего времени, и более 50% из этого фактически загружает все файлы .module и .inc. Это не то, что вы можете хранить в memcache. Кроме того, это не имеет большого значения, если я использую memcache или кэш базы данных.

Я пытался получить некоторые результаты, когда кеш страниц включен, но Xhprof, похоже, не дает надежных результатов; все кажется слишком быстрым. Но даже тогда большая часть включает в себя выполнение перехватов init / exit и загрузку файлов, как кажется. Там я обнаружил интересную проблему: похоже, что пользовательский модуль серьезно замедляет отклик кэшированной страницы, потому что он запускает реестр из-за контроллера сущностей в файле .module.

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

Что действительно плохо в Drupal 7, так это слой рендера с этими огромными массивами, бесконечными рекурсиями и циклами. Это в значительной степени отменяет всю работу над производительностью, которая шла в Drupal 7. Давайте посмотрим, как это выглядит в Drupal 8, если Twig превратит его в ядро.

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

Нет, это был Дэвид Стросс, который экспериментировал с kargo-event (теперь он называется Kellner) на https://code.launchpad.net/~fourkitchens/pressflow/6-evented, но я сомневаюсь, что из этого вышло что-то серьезное.

В Drupal 7 уже есть много загрузочных кешей, для этого есть cache_bootstrapкорзина. Вы можете вставить его в memcached.

Вы можете пойти за борт и уменьшить загрузку кода, переместив некоторые / много кода Drupal в C. Damien и dhthwy создали расширение PHP на http://drupal.org/project/drupal_php_ext, с которым мало что делается. Или сделать хип-хоп. Я не знаю текущее состояние хип-хопа и Drupal 7.

В конце концов, однако, вам необходимо тщательно изучить инженерные затраты, скажем, на работу в хип-хопе с Drupal 7 (и всеми участниками!) И сравнить ее с арендой еще нескольких серверов. Если вы можете сэкономить, скажем, 5% ваших серверов, и у вас есть 100 000 серверов, пойти на это, но вы Facebook? Будьте осторожны и экономны с оптимизацией.

Увидел интересную презентацию о doh (Dynamic Object Handler) на встрече High Performance Drupal . Короче говоря, он говорит о быстрой загрузке Drupal с помощью этого. Интересен около 15:30. Короче автозагрузка на стероидах с функциональным рункитом . QA на отметке 33:00.