- Publié le 17 Janvier 2010 à 23:42
Après les déboires récents de mon premier serveur Dedibox, j'ai reçu courant décembre un mail m'annonçant la fin du support de ma Dedibox V1 fin janvier 2010 et l'obligation de migrer vers une autre machine. J'envisageais depuis un bon moment de changer de serveur, cela n'a fait que précipiter les choses. Et j'ai finalement choisi un serveur Kimsufi 750G qui semble mieux fourni que les Dedibox XL pour le même prix (aux frais d'installation près si on paie pas à l'année).
La migration à l'identique est quasiment terminée mais je compte bien exploiter au mieux les 4Go de RAM (quel changement en comparaison du Go que j'avais avant). Je vais m'intéresser de plus près à la configuration de MySQL pour exploiter ces nouvelles ressources et je vais enfin pouvoir installer l'extension eZ Find sur mes différents sites eZ Publish.
En attendant un rapide benchmark sur pwet.fr avec siege sur les 200 pages les plus vues m'a montré que cette machine est capable de servir quelque chose comme 40 pages / seconde sans broncher là ou l'ancienne machine était capable de servir péniblement 7 pages / secondes. Il y a de la place pour quelques nouveaux projets!
- Publié le 13 Septembre 2009 à 16:00
Après un peu plus de 2 ans et demi de bons et loyaux services (malgré quelques aléas ponctuels), il semble que ma première Dedibox ait quelques soucis. Samedi matin, elle a planté mais impossible de la faire redémarrer malgré l'utilisation du système de secours pour vérifier les trucs habituels (fsck très long, mauvais paramètrage du grub, ...). Bref, j'ai migré les sites sur mon second serveur, le temps que la propagation des DNS se fasse, et revoila Planet eZ Publish.fr, Bioutifoul Photos et pwet.fr à nouveau en ligne. Au passage, des backups fonctionnels, ça simplifie énormément les choses :-) J'envisage depuis un bon moment de prendre un serveur plus puissant type Dedibox XL ou Kimsufi 750G, au moins j'ai éprouvé la migration potentielle.
Pour revenir à cette Dedibox, j'ai refait une installation propre de Debian. Malgré l'absence totale de charge et un test matériel normal, elle a à nouveau planté ce matin. La messe est dite, RIP Dedipwet.
- Publié le 01 Avril 2009 à 21:54
C'est la saison des benchmarks autour d'eZ Publish :) Bertrand a fait une intéressante comparaison entre le mode cluster et le mode classique, suivi de près par un article sur ez.no mettant en évidence le gain apporté par le fameux Stale Cache dans la génération du cache de contenu. De mon côté, j'ai adapté les scripts de mon benchmark entre eZ Publish 3.10 et eZ Publish 4 pour comparer cette fois uniquement les performances sur une page en cache de ce site (/blog) avec eZ Publish 4.0.1, eZ Publish 4.1 sans optimisation et eZ Publish 4.1 avec un fichier config.php ; le but étant de déterminer le gain apporté par les différentes améliorations de performances pour un site sur un seul serveur.
Informations techniques
- Serveur : une Dedibox v1 ancienne génération (processeur Via C7 à 2Ghz avec 1Go de RAM)
- Logiciels : Apache 2.2.8, PHP 5.2.4 avec le module xcache, MySQL 5.0.51
- Caractéristique de la page : la page fait les 3 requêtes SQL minimum (session, chargement des langues et détermination de la page concernée)
- Test : plusieurs séries de 500 requêtes avec un concurrence de 2 réalisées avec l'utilitaire ab sur chacune des installations
Le fichier config.php :
<?php
define( 'EZP_USE_BUNDLED_COMPONENTS', true );
define( 'EZP_INI_FILEMTIME_CHECK', false );
?>
Résultats
Le résultat est plutôt spectaculaire. La simple mise à jour en 4.1 donne un gain de presque 30% dans la distribution d'une page en cache ! Avec la configuration ci-dessus dans le fichier config.php le gain est même de 50% ! Pendant les phases de tests, j'ai également constaté que la charge de la machine est bien plus faible. Comme d'habitude ces chiffres sont à prendre avec des pincettes, ils représentent le gain sur un site bien optimisé (enfin j'espère) sur un serveur bas de gamme. Un test sur un serveur plus haut de gamme serait vraiment intéressant.
- Publié le 27 Janvier 2009 à 22:09
Suite et fin de la série d'articles sur la réalisation du Planet eZ Publish.fr avec les questions de performances et de caches.
I. Organisation et Import des articles
II. Modules/vues sur mesure et templates
III. Performances : caches et compagnie
Performances
Cache de vue et cache-block
La gestion des caches « standards » est un point important pour les performances. La vue full (zone entourée de jaune dans la capture d'écran ci-dessus) est assez logiquement l'affichage de la liste des articles, elle est automatiquement mise en cache (cache de vue ou cache de contenu). Pour que la page d'accueil et les pages Blogs et Planétarium soient à jour sans opération manuelle, il m'a fallu ajouter deux règles dans une surcharge du fichier viewcache.ini pour que le cache de vue soit vidé lors de l'ajout d'un objet de la classe Post ou de la classe Site.
Les menus (menu horizontal, liste des blogs, liste des planets) sont chacun entourés d'une instruction cache-block (cadres rouge) expirant avec la partie de l'arborescence qu'ils affichent. Et pour aller encore un peu plus loin, chaque article est lui-même individuellement mis en cache par un cache-block. Cela permet de limiter le nombre de requêtes SQL nécessaires à la re-génération de la vue full lors de l'ajout ou de la mise à jour d'un article ainsi que sur l'affichage des résultats de recherche.
Cache statique
Compte tenu du faible nombre de pages, j'ai choisi d'ajouter du cache statique en plus des caches classiques sur l'ensemble du site. 0,05 seconde pour sortir une page les mauvais jours, difficile de faire mieux ! Une des limitations du cache statique est l'impossibilité de pré-générer les pages avec paramètres (par exemple /page/(offset)/10), pour éviter ce problème, j'ai ajouté les pages principales (avec ou sans paramètres) dans les URLs à générer systématiquement. Ainsi à la moindre modification de contenu, le script de cronjob staticcache_cleanup.php génère la quinzaine de pages du site. Ce qui a aussi l'avantage de pré-générer les zones en cache détaillées précédemment pour les résultats de recherche par exemple.
Optimisations côté navigateur
Le temps de génération (ou de distribution) des pages n'est qu'une petite partie du temps total d'affichage de la page. Les Yahoo! Performances Rules ou le livre High Performances Web Sites listent les principales recommandations pour améliorer ce point.
Planet eZ Publish.fr est hébergé sur ma Dédibox, la configuration des entêtes d'expiration et de la compression GZip des éléments textuels sont effectifs. La charte graphique simple a également simplifiée la mise en place de la technique CSS Sprites pour limiter le nombre de requêtes HTTP nécessaire à l'affichage d'une page. Tout ceci donne un beau Performance Grade A(97) dans YSlow.
