Actualités

[16/10/2014] L'édition 2014 du livre blanc de Smile : "Bonnes pratiques du web"

Smile publie une nouvelle version du livre blanc "Bonnes pratiques du web – Toutes les clés pour concevoir son site web". A télécharger gratuitement !

[14/10/2014] Smile vous donne RDV sur les forums de recrutement de 2014-2015 !

Vous aimez le web et les technologies de pointe, vous souhaitez mettre votre expertise au service du meilleur de l’open source ? Venez rencontrer Smile durant les prochains forums écoles de cette année 2014-2015.

[13/10/2014] Smile, partenaire de la 7ème édition de l'Open World Forum

L’Open World Forum 2014 se tiendra les 30 et 31 Octobre à l’Eurosites George V, à Paris. Pour cette édition, la ligne force est : "Take Back Control". Inscriptions gratuites !

Toutes les actualités picto
       

Vous avez besoin de mettre à jour votre Lecteur Flash Flash 7

Guillemet ouvrant l'actualité des solutions
et des technologies open source Guillemet fermant
picto

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...

  1. Développeur et utilisateur d'eZ Publish depuis un peu plus de 2 ans
  2. Réalisation ou participation à une trentaine de projets utilisant eZ Publish
  3. tigrou sur #ezpublish
  4. mon blog pwet.fr/blog sur planetezpublish.org

Smile

  1. Partenaire Gold
  2. Environ 200 collaborateurs
  3. 4 Agences : Paris, Lyon, Nantes et Montpellier
  4. 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
    1. détection de modification / publication / suppression
    2. remplissage d'une table d'évènements
    3. exécution périodique d'un script déterminant les fichiers à générer
    4. 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
picto

Commentaires

Soyez la premiere personne à ajouter un commentaire sur cet article.
Ecrire un nouveau commentaire