Actualités

[17/07/2014] Retrouvez la vidéo du Webinar : Etre autonome sur sa communication web

Découvrez la vidéo du webinar Ametys et Smile, pour bénéficier des retours d’expérience de la Ville de Cannes et voir comment la collectivité utilise la solution de gestion de contenu Ametys pour gérer l'ensemble de ses portails web et accroître leur visibilité.

[07/07/2014] Découvrez le nouveau site de Smile e-Commerce Performances

E-commerçants, ne laissez pas votre site ralentir votre chiffre d'affaires ! Sur le site e-Commerce Performances, découvrez comment les innovations technologiques permettent d'améliorer les performances de votre site e-commerce en Magento.

[03/07/2014] Bargento 2014 cible le top market du e-commerce

Pour la première fois, Smile et NBS System s’associent pour organiser le plus grand rassemblement français autour de la technologie Magento. Tout l'écosystème sera présent et des centaines de grands comptes utilisateurs de Magento sont attendus. L'Appel à contribution est dès à présent ouvert aux propositions de sujets de conférences.
Rendez-vous le mardi 7 octobre à Paris Espaces CAP 15 !

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