Mise en cache du bootstrap Drupal

Je suis curieux de savoir si quelqu'un a tenté de "mettre en cache" le processus d'amorçage dans Drupal.

Normalement, Drupal exécutera les 7 phases d'amorçage à chaque demande, mais peut-être que sur un système de production déployé, on pourrait "supprimer" tout ou partie de ces éléments?

Les suggestions que j'ai en tête pourraient être

1. Sérialiser l'état amorcé et le coller dans memcache
2. Un script pourrait générer un correctif pour bootstrap.inc qui codera en dur certaines informations dans le fichier.
3. Je crois que David Strauss a essayé de garder un Drupal amorcé fonctionnant sur libevent.
4. Autre folie?

Quelles tentatives existe-t-il et lesquelles sont réputées (quelque peu) fiables?

PHP est une architecture de partage rien. Cela a ses avantages et ses inconvénients.

Un inconvénient est qu'il n'est pas facile de faire quelque chose comme ça. Il n'y a pas beaucoup d'état qui puisse être stocké quelque part.

J'ai fait quelques tests rapides et une fois connecté, le boostrap semble prendre environ 17% du temps total et plus de 50% de celui-ci est en train de charger tous les fichiers .module et .inc. Ce n'est pas quelque chose que vous pouvez stocker dans memcache. En outre, cela ne semble pas avoir beaucoup d'importance si j'utilise memcache ou le cache de base de données.

J'ai essayé d'obtenir des résultats lorsque le cache de page était activé, mais Xhprof ne semble pas alors renvoyer des résultats fiables; le tout semble tout simplement trop rapide. Mais même dans ce cas, la plus grande partie implique l'exécution de hooks init / exit et le chargement de fichiers semble-t-il. J'ai trouvé un problème intéressant là-bas: il semble que le module utilisateur ralentit sérieusement la réponse de la page en cache car il déclenche le registre en raison du contrôleur d'entité dans le fichier .module.

Cela dit, David Strauss a montré un travail expérimental à Copenhague où il a créé un instantané de la mémoire après avoir démarré, puis y revenir une fois la page servie. Il a utilisé Drupal 6 pour cela. Après avoir regardé les chiffres ci-dessus, j'imagine que les gains de performances de faire cela dans Drupal 7 seraient un peu plus petits. Une des raisons à cela est que la connexion à la base de données est chargée paresseusement (et vous pouvez aller assez loin dans le bootstrap lorsque vous utilisez par exemple Memcache avant de devoir exécuter la première requête) et il y a beaucoup de choses qui sont mises en cache.

Ce qui est vraiment mauvais dans Drupal 7, c'est la couche de rendu avec ces énormes tableaux et ces récursions et boucles sans fin. Celui-ci annule à peu près tout le travail de performance qui est allé dans Drupal 7. Voyons à quoi il ressemble dans Drupal 8, si Twig en fait un noyau.

Enfin, sur les avantages mentionnés. Un gros avantage est que les poireaux de mémoire sont plutôt hors de propos car tout est libéré après chaque requête. J'ai vu de nombreuses applications Java où l'utilisation de la mémoire augmente constamment et nécessite des redémarrages réguliers.

Non, c'était David Strauss qui expérimentait avec kargo-event (maintenant appelé Kellner) sur https://code.launchpad.net/~fourkitchens/pressflow/6-evented mais je doute que quelque chose de sérieux en soit sorti.

Drupal 7 n'ont beaucoup de bootstrap déjà mis en mémoire cache, il y a une poubelle pour cela. Vous pouvez le coller dans memcached.cache_bootstrap

Vous pouvez aller trop loin et réduire le chargement de code en déplaçant une partie / beaucoup de code Drupal vers C. Damien et dhthwy ont créé l'extension PHP sur http://drupal.org/project/drupal_php_ext . Ou faites du hiphop. Je ne connais pas l'état actuel de hiphop & Drupal 7.

À la fin de la journée, cependant, vous devez examiner attentivement les coûts d'ingénierie, par exemple, pour faire travailler hiphop avec Drupal 7 (et toutes les contributions!) Et le comparer avec la location de quelques serveurs supplémentaires. Si vous pouvez économiser, disons 5% de vos serveurs et que vous avez 100 000 serveurs, allez-y, mais êtes-vous Facebook? Soyez prudent et économique avec des optimisations.

J'ai vu une présentation intéressante sur doh (Dynamic Object Handler) lors du Meetup High Performance Drupal . En bref, il parle de démarrer rapidement Drupal en l'utilisant. Obtient intéressant autour de la marque de 15h30. Autoload sur les stéroïdes en bref avec runkit également fonctionnel. QA à 33h00.