Optimisation d'un site Plone
Un site web Plone est plus lourd et plus lent qu'un site développé (correctement) en PHP/MySQL. C'est un fait. Forcément, il n'y a pas toute la machinerie Zope derrière : gestion des droits, groupes et utilisateurs, moteur de worklows, etc... Un site développé en PHP/MySQL peut ne prendre que quelques lignes de code, alors que le même site fait avec Zope / Plone sera beaucoup plus gros, et de ce fait, gourmand en ressources.
Pour un petit site, la différence n'est pas énorme, par contre, si le site commence à être conséquent, optimiser son code devient crucial.
Pour optimiser un site Plone, on peut identifier trois phases :
- Utiliser de bonnes pratiques de développement
- Répartir la charge
- Mettre en place un système de cache
Utiliser de bonnes pratiques de développement
Le portal_catalog
Lorsque l'on veut accéder à un objet, Zope doit "réveiller" cet objet, malheureusement, "réveiller" un objet est très coûteux. Cela l'est encore plus lorsque l'on veut afficher une liste et que chaque objet de cette liste est "réveillé".
Pour éviter de "réveiller" inutilement les objets, Plone dispose d'un catalogue : le portal_catalog.
Il permet d'indexer les objets (index) et de stocker certains champs des objets (metadata). Pour afficher une liste d'objets avec leur titre et un lien vers l'objet en lui même, plus besoin de "réveiller" tous les objets de la liste.
Les index vont vous servir lors des recherches dans le catalogue, alors que les metadata permettent d'accéder aux données de l'objet sans avoir à le "réveiller". Il est très simple de rajouter des index et des metadata dans le portal_catalog, que ce soit directement depuis la ZMI ou programmatiquement.
Au lieu de :
<a tal:attributes="href python:item.getObject().absolute_url()" tal:content="item.getObject().title_or_id">Mon Objet</a>
Préférez plutôt :
<a tal:attributes="href item/getURL" tal:content="item/Title">Mon objet</a>
Les scripts python
Lorsque vous créez des scripts python, au lieu de passer par la ZMI qui va faire plusieurs vérifications à chaque instructions, stockez les directement sur le File System, dans votre produit. Non seulement vous gagnerez en performance, mais en aussi en productivité. C'est beaucoup plus simple d'éditer un script python depuis son éditeur de texte favoris que depuis un formulaire web.
Une autre méthode est de créer un tool, ou d'utiliser les vues Zope 3 (via Five)
Répartir la charge
De base, nous avons une instance Zope avec sa ZODB (Zope Object Data Base). L'instance Zope reçoit les requêtes HTTP, effectue le rendu de la page et s'occupe de stocker les objets dans la ZODB.

image provenant de la présentation de Pilot Systems
Une installation simple
Une façon d'optimiser très simplement un site Plone est de mettre un serveur Apache en frontal devant l'instance Zope. Cette installation est suffisante pour les petits site à faible trafic. Par contre, il n'y a pas de tolérance de panne, et la montée en charge reste faible. Les performances du site ne sont que très faiblement accrues.

image provenant de la présentation de Pilot Systems
Répartition de charge avec ZEO
ZEO (Zope Enterprise Object), permet de diviser Zope en deux :
- Une partie serveur pour stocker les données
- Une partie cliente pour effectuer le rendu des pages et recevoir les requêtes HTTP.

image provenant de la présentation de Pilot Systems
L'avantage ici, est que l'on peut créer autant de clients que l'on veut. Le serveur ZEO peut être sur une machine physique différente des autres clients ZEO, et chaque client peut aussi être sur une machine physique différente.
Les clients sont tous relié au serveur ZEO. On peut répondre très facilement à une monté en charge : il suffit de rajouter des clients ZEO.
On peut dédier un client (ou plusieurs) pour l'administration du site, et ainsi améliorer les performances pour l'administration du site, sans dégrader les performances coté "publique".
Mettre en place un système de cache
La première solution est de mettre en place un serveur SQUID qui permet de gérer du cache. Il limite les requêtes vers les clients ZEO en retournant les pages en cache.
En complément de SQUID, Pound permet de répartir la charge entre les différents clients ZEO, (à noter que SQUID peut le faire aussi). Si un des clients ZEO n'est plus accessible, Pound redirige automatiquement les requêtes vers un autre client disponible.

image provenant de la présentation de Pilot Systems
Cette infrastructure est optimum, elle permet d'avoir un site complètement optimisé, avec très peu de requêtes traitées par Zope, le cache se situant en amont.
Si une panne survient sur un des clients ZEO, les autres prennent le relais, cela nous permet de réparer le client défectueux sans que les utilisateurs soient pénalisés.
Si l'audience du site augmente, il suffit de rajouter un ou plusieurs clients ZEO.
L'optimisation d'un site Plone passe par beaucoup d'étape, que ce soit au niveau de l'infrastructure comme du code produit. Heureusement, pour l'infrastructure, on peut commencer juste par avoir un apache en frontal, puis ajouter des clients ZEO et un SQUID si le besoin se fait ressentir.
Il est par contre plus fastidieux de revenir sur du code produit, il faut donc tout de suite adopter de bonnes pratiques de programmation.
Merci à Sylvain Viollon de Pilot Systems pour sa présentation lors des Solutions Linux 2007.
Abonnez vous au flux RSS du blog |
