Actualités

[24/11/2014] De nouveaux locaux pour Smile Lille, Lyon et Marseille !

Trois agences de Smile ont déménagé ces deux dernières semaines. De nouveaux locaux plus spacieux ont été investit pour accompagner la croissance et le développement de ces agences Lilloise, Lyonnaise et Marseillaise.

[19/11/2014] Portails d'entreprise, la nouvelle version du livre blanc Smile

Qu'est-ce qu'un portail d'entreprise ? Quels sont ses fonctionnalités et domaines d'application ? Quelles sont les meilleures solutions du marché ? C'est à découvrir dans le livre blanc Smile !

[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 !

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