Mise en cache du Drupal bootstrap
Je suis curieux de savoir si quelqu'un a tenté de "mettre en cache" le processus bootstrap dans Drupal.
Normalement, Drupal exécutera les 7 phases bootstrap sur chaque demande, mais peut-être sur un système de production déployé, on pourrait "supprimer" tout ou partie de celles-ci?
Les suggestions que j'ai en tête pourraient être
- Sérialiser l'état amorcé et le coller dans memcache
- Un script pourrait générer un correctif pour bootstrap.inc qui codera en dur certaines informations dans le fichier.
- Je crois David Strauss a essayé de garder un bootstrap Drupal fonctionnant sur libevent.
- Autre folie?
Quelles tentatives existe-t-il et lesquelles sont connues pour être (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 est la couche de rendu avec ces énormes tableaux et récursions et boucles sans fin. Celui-ci annule à peu près tout le travail de performance qui a été effectué dans Drupal 7. Voyons à quoi il ressemble dans Drupal 8, si Twig en fait le 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) à https://code.launchpad.net/~fourkitchens/pressflow/6-evented mais je doute que quelque chose de sérieux soit venu en dehors de ça.
Drupal 7 a beaucoup de bootstrap déjà mis en cache, il y a un cache_bootstrap bin pour ça. Vous pouvez le coller dans memcached.
Vous pouvez aller trop loin et réduire le chargement de code en déplaçant une partie/beaucoup de code Drupal dans C. Damien et dhthwy a créé PHP sur http: //drupal.org/project/drupal_php_ext il n'y a pas grand chose à faire. Ou faire du hiphop. Je ne connais pas l'état actuel du hiphop & Drupal 7.
À la fin de la journée, cependant, vous devez examiner attentivement les coûts d'ingénierie de, disons, 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 les optimisations.
Vu une présentation intéressante à propos de doh (gestionnaire d'objet dynamique) au High Performance Drupal meetup . En bref il parle de bootstrapping drupal rapide en l'utilisant. Obtient intéressant autour de la marque 15:30. Autoload sur les stéroïdes en bref avec runkit fonctionnellement QA à 33:00.