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


10

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

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

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

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

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


Это как-то связано с моим вопросом о компиляции Drupal: drupal.stackexchange.com/q/11738/2916
Refineo

Ответы:


12

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-приложений, где использование памяти постоянно увеличивается и нуждается в регулярных перезапусках.


4
Мне так нравится, что ты на сайте @Berdir;)
Летарион,

Алекс Бронштейн упомянул об этом во время спринта, что включать файлы tpl.php довольно медленно, даже с APC, он требует stat - но Twig компилирует классы, так что это будет победой на таких страницах, как node + много комментариев. Посмотрим.

Я думаю, вы могли бы создать систему, в которой для кэшированных страниц вы генерируете кучу правил перезаписи и помещаете их в .htaccess, сопровождаемый html-страницами, чтобы полностью обойти PHP. Хотя это может не стоить хлопот: IIS, nginx, вошедшие в систему пользователи, ...
Барт

1
@Bart: Вы только что заново изобрели Boost: drupal.org/project/boost :)
Бердир,

5

Нет, это был Дэвид Стросс, который экспериментировал с 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? Будьте осторожны и экономны с оптимизацией.


Спасибо, я обновил вопрос и удалил ваше имя из него. :) Я понимаю, что во многих случаях есть гораздо более эффективные способы борьбы с производительностью, мне было в основном любопытно.
Летарион

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.