eZ publish à très hautes performances
Avec des techniques des publication statique, eZ publish peut être déployé sur des sites à très hautes performances
Présentation de Damien Pobel, au Partner Meeting eZ publish, à Paris le 31 octobre 2007
Présentation
Moi...
- Développeur et utilisateur d'eZ Publish depuis un peu plus de 2 ans
- Réalisation ou participation à une trentaine de projets utilisant eZ Publish
- tigrou sur #ezpublish
- mon blog pwet.fr/blog sur planetezpublish.org
Smile
- Partenaire Gold
- Environ 200 collaborateurs
- 4 Agences : Paris, Lyon, Nantes et Montpellier
- Plus de 50 projets eZ publish, dont : voyages-sncf.com, INRA, OSEO, Velib', Yves Rocher, femmeactuelle.com, Bouygues Telecom, ...
Performances d'eZ Publish en quelques chiffres
Performances d'eZ Publish
- 18 pages/secondes par processeur selon un article de Bård Farstad
- › environ 65000 hits/heure ou 1.5 millions hits/jour
- › limite "brute théorique", en pratique environ 1.5 fois moins
- › vivement eZ Publish 4 ;-) (2 à 4 fois plus rapide)
- Avec des pages complètement statiques, on peut tenir 50 fois plus sans problème
- Temps de chargement d'une page avec caches générés : environ 500ms
- › quasiment directement lié au nombre de requêtes SQL
- Une page statique c'est moins de 100ms
View Cache et cache-block
- Principaux mécanismes permettant d'obtenir ces performances
- › View Cache = correspond au stockage du $module_result.content
- › cache-block = instruction du langage de template de mise en cache
Cache statique
Principe
- Génération de pages statiques complètes par eZ Publish au moment de la publication
- › configurable sur une partie d'un site uniquement
- › une RewriteRule Apache permet la distribution ou non du fichier statique en fonction de son existence
- › mécanisme facile à étendre sur un mode asynchrone sur quelques pages clés
- › adapté aux sites relativement... statiques !
Avantages
- Intégration à eZ Publish
- Relative simplicité de mise en place
Inconvénients
- Ralentissement du back office car la génération est synchrone
- Ne fonctionne pas avec les pages à paramètres (pagination, ...)
- Impose l'utilisation de javascript pour la personnalisation des pages en fonction de l'utilisateur
Mode « cluster »
Principe
- Tout ce qui est relatif au contenu est stocké en base de données
- les fichiers binaires (images, contenu à télécharger, ...)
- les caches relatifs aux contenus (ViewCache, cache-block, ...)
- › pouvoir multiplier les serveurs frontaux pour tenir la charge
- › éventuellement multiplier les serveurs de base de données
- › configuration adaptée à des sites « dynamiques »
- Attention : tout est sorti de la base de données
- › un reverse proxy (Squid, Varnish, ...) est conseillé au moins pour les images
Avantages
- scalabilité, il suffit de rajouter des serveurs frontaux.
- d'un point de vue développement, il est assez simple pour tous les développeurs d'avoir un unique référentiel
Inconvénients
- nombre de serveurs élévés
- complexité d'administration système
- incompatibilité avec certaines fonctionnalités, par ex: textoimage (bug ?)
- adaptations nécessaires des extensions pour utiliser la couche d'abstraction de gestion des fichiers
Génération statique (1/4)
Situation
- Site à fort trafic
- › 2 millions de pages vues/jour
- › 450000 pages vues/heure
- › 140 pages/sec à l'heure de pointe
- › l'architecture doit permettre de tenir 5 à 10 fois plus
- Site avec beaucoup de contenus et de mises à jour
- › 80000 objets
- › 150 nouveaux contenus par jour
- › maximum 3 minutes entre la validation d'un contenu et son apparition sur le site
- › le backoffice doit rester très réactif pour ne pas perdre de temps en rédaction
- Impossible d'utiliser le cache statique
- › ralentit le backoffice
- › remontées d'informations sur certaines pages, nécessité de régénérer de milliers de pages
- Mode cluster pas tout à fait adapté
- › nécessiterait beaucoup de machines
- › difficulté à tenir les pics
Génération statique (2/4)
Solution
- Génération de morceaux de HTML
- › découpage des templates en vues indépendantes, affichage normal sur le serveur de test, code SSI en mode génération
- › génération des blocs de HTML indépendants via le mécanisme de layout
- Règles de génération
- › première solution hack kernel en remplaçant les appels de génération du cache statique, mais problème de transactions MySQL
- › seconde solution : utilisation de triggers MySQL
- détection de modification / publication / suppression
- remplissage d'une table d'évènements
- exécution périodique d'un script déterminant les fichiers à générer
- exécution périodique du script de génération
- Assemblage et distribution par Apache via le module mod_ssi (Server Side Include) avec un temps d'expiration de 3 minutes
- Mise en cache par le reverse proxy Squid pour éviter l'assemblage de la page à chaque appel
Génération statique (3/4)
Architecture : 10 serveurs
Génération statique (4/4)
Avantages
- Tenue en charge (frontaux à moins de 10% CPU)
- Adaptation simple pour faire encore plus : ajout de frontaux
- Fonctionnement correct même si MySQL crashe puisque 99% du site est prégénéré
- Adaptable sur beaucoup de sites, seules les règles de générations de changent
Inconvénients
- Lors d'une mise à jour de templates, il faut parfois regénérer énormément de fichiers
- Adaptation des templates nécessaires
- Mise au point délicate (oubli de génération, gestion de la pagination, ...)
- Utilisation de javascript pour la personnalisation
Questions ?
Damien Pobel
Commentaires