Buforowanie bootstrapu Drupal

Jestem ciekawy, czy ktoś podjął próbę „buforowania” procesu ładowania początkowego w Drupal.

Zwykle Drupal będzie uruchamiał 7 faz ładowania początkowego przy każdym żądaniu, ale być może w wdrożonym systemie produkcyjnym można „pozbyć się” niektórych lub wszystkich z nich?

Możliwe sugestie, które mam na myśli, mogą być

1. Serializacja stanu ładowania początkowego i umieszczanie go w pamięci podręcznej
2. Skrypt może wygenerować łatkę dla bootstrap.inc, która utrwali pewne informacje w pliku.
3. Wydaje mi się, że David Strauss próbował utrzymać Drupala w bootstrapie działającym na libevent.
4. Inne szaleństwo?

Jakie są próby i które są (w pewnym stopniu) wiarygodne?

PHP to wspólna architektura niczego. Ma to swoje zalety i wady.

Wadą jest to, że nie jest łatwo zrobić coś takiego. Nie ma wiele stanów, które można gdzieś zapisać.

Zrobiłem kilka szybkich testów, a po zalogowaniu się, wydaje się, że boostrap zajmuje około ~ 17% całkowitego czasu, a ponad 50% z tego to ładowanie wszystkich plików .module i .inc. To nie jest coś, co można przechowywać w memcache. Ponadto nie wydaje się mieć większego znaczenia, jeśli używam pamięci podręcznej lub pamięci podręcznej bazy danych.

Próbowałem uzyskać pewne wyniki przy włączonej pamięci podręcznej stron, ale Xhprof nie wydaje się wtedy zwracać wiarygodnych wyników; wszystko wydaje się po prostu za szybkie. Ale nawet wtedy największa część polega na wykonywaniu haków inicjujących / wyjściowych i ładowaniu plików. Znalazłem tam interesujący problem: wygląda na to, że moduł użytkownika poważnie spowalnia odpowiedź strony w pamięci podręcznej, ponieważ uruchamia rejestr z powodu kontrolera encji w pliku .module.

To powiedziawszy, David Strauss pokazał pewne prace eksperymentalne w Kopenhadze, gdzie stworzył migawkę pamięci po bootstrapowaniu, a następnie powrócił do tego po wyświetleniu strony. Użył do tego Drupala 6. Po przyjrzeniu się powyższym liczbom wyobrażam sobie, że wzrost wydajności robienia tego w Drupal 7 byłby nieco mniejszy. Jednym z powodów tego jest to, że połączenie z bazą danych jest leniwie załadowane (I możesz dostać się dość daleko w bootstrap, używając np. Memcache, zanim będziesz musiał wykonać pierwsze zapytanie) i jest wiele, które są buforowane.

To, co naprawdę złe w Drupal 7, to warstwa renderowania z tymi ogromnymi tablicami i niekończącymi się rekurencjami i pętlami. Ten w zasadzie odwraca całą pracę związaną z wydajnością w Drupal 7. Zobaczmy, jak to wygląda w Drupal 8, jeśli Twig przekształci się w rdzeń.

Wreszcie o wspomnianych zaletach. Dużą zaletą jest to, że pory pamięci są raczej nieistotne, ponieważ wszystko jest zwalniane po każdym żądaniu. Widziałem wiele aplikacji Java, w których zużycie pamięci stale rośnie i wymagają regularnych restartów.

Nie, to David Strauss eksperymentował z wydarzeniem kargo (teraz nazywanym Kellner) pod adresem https://code.launchpad.net/~fourkitchens/pressflow/6-event, ale wątpię, żeby coś poważnego z tego wynikło.

Drupal 7 ma już dużo buforowania bootstrap, jest na to cache_bootstrapkosz. Możesz włożyć go do memcached.

Możesz przejść za burtę i zmniejszyć ładowanie kodu, przenosząc część / wiele kodu Drupala do C. Damien i dhthwy utworzyli rozszerzenie PHP na http://drupal.org/project/drupal_php_ext niewiele z tym zrobić. Lub zrób hiphop. Nie znam obecnego stanu hiphopu i Drupala 7.

Jednak pod koniec dnia musisz dokładnie przyjrzeć się kosztom inżynierii, powiedzmy, rozpoczęcia pracy w hiphopie z Drupalem 7 (i całym wkładem!) I porównać to z wynajęciem kilku innych serwerów. Jeśli możesz zaoszczędzić, powiedzmy 5% swoich serwerów i masz 100 000 serwerów, idź, ale czy jesteś Facebookiem? Bądź ostrożny i oszczędny dzięki optymalizacjom.

Zobaczyłem interesującą prezentację o doh (Dynamic Handler Object) w meetup High Performance Drupal . Krótko mówiąc, mówi o szybkim ładowaniu drupala przy użyciu go. Staje się interesujący około 15:30. Autoload na sterydach w skrócie z runkit funkcjonalnie, jak również. Kontrola jakości o godzinie 33:00.