Tag - eZ publish - Karlesnine.com

jeudi, décembre 10 2009

Configurer le niveau de compression du Mode_deflate de Apache2 et utiliser les logs pour en connaitre l'efficacité

Par Charles-Christian Croix le jeudi, décembre 10 2009, 11:08 - Technologic

Pour compléter mon billet sur l'utilisation du mod_deflate pour un hébergement apache 2 de Dotclear2 et celui sur Optimisation d'un hébergement eZ Publish 4 pour l'utilisation des caches web ou je parle du mod_gzip de apache 1.3 je vous invite à consulter le billet use mod_deflate to compress web content delivered by apache sur g-loaded.eu. Cette recommandation est valable quelque soit le CMS ou application web du moment que votre solution de web hosting repose sur apache 2. Vous en apprendrez plus sur les points suivants :

Configurer le niveau de compression de mod_deflate

L'algorithme deflate est assez rapide et il est possible de modifier le niveau de compression. Le mettre au maximum ne pose pas de problème si vous vous contentez de compresser du texte (css, Js, xml etc) ^[1]

DeflateCompressionLevel 9

Surveiller la compression via les logs

Vous pouvez avoir une trace log de la compression effectué par le mod_deflate de votre serveur apache 2.^[2]

Le directive suivant définissent quelque variable :

instream : La taille en Bytes (Octet) en entré de DEFLATE.
outstream : La taille en Bytes (Octet) en sortie de DEFLATE.
ratio : Le ratio de compression, (Sortie/Entré)x100

DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio

Les variables définie vous pouvez ajouter une Format de log à votre vhost:

LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflatelog

N'oubliez par d'utiliser de format de log en l'écrivant dans un fichier de log.

CustomLog /path/to/vhost/logs/deflate_log deflatelog

Vous obtenez un log pour deflate qui ce présente comme cela. Pratique pour étudier l'utilité de la compression de donner en fonction du type de fichier dans votre architecture d'hébergement ou des efforts de Minification, toujours important en web hosting.

"GET /dotclear/themes/default/js/jquery.cookie.js HTTP/1.1" 451/994 (45%)

Notes

[1] Attention comprimer au maximum des fichiers trop gros ou déjà compressé comme les images est contre productif !!

[2] Attention écrire des logs sur le disque ralenti apache !!

2 commentaires

vendredi, octobre 30 2009

Voici.fr résultat d'optimisation des images

Par Charles-Christian Croix le vendredi, octobre 30 2009, 11:44 - Technologic

Pour illustré mes recommandations sur l'optimisation des images pour l'accélération d'un site web je me suis amusé à optimisé le contenue du storage eZ publish de voici.fr. Le storage qui est basé sur eZFS qui permet de stocker les binaires sur disque (donc les images) et de les partager via NFS je n'ai donc eu aucun mal à accéder au image et à pratiquer un test.

Etat initial

J'ai recopier le répertoire /var/www/voici.fr/var/siteaccess/storage sur une machine virtuel de notre architecture de développement et j'ai ensuite fais l'inventaire de cette arborescence.

9,9 Go
207075 fichiers
326 fichiers png
5 fichiers jpeg
195883 fichiers jpg

Nettoyage jpegtran

J'ai lancer un nettoyage des fichiers jpg avec jpegtran, celui ci à duré 5 heures mais j'avais à ma disposition que 1 core de Xeon et 1Go de Ram.

real    320m39.499s
user    37m44.520s
sys     227m19.910s

Au final j'obtient une taille total de 9,3Go pour /var/www/voici.fr/var/siteaccess/storage. J'espérais un gain supérieur mais en même temps cela indique que les images uploader répondre déjà à un charte précise et sont normées.

Analyse du gain

Le gain de 300 Mo peux sembler totalement inutile à l'heure des disques SATA à 1To si seul le stockage était jeu. Or l'important est de gagner quelque point sur la diffusions. Dans la cas présent tout les 10Go nous gagnons 300Mo. Si je spécule sur le volume total de donnée transférer par mois pour voici.fr c'est près de 100Go de donnée en moins que nous avons à diffuser chaque mois. Reporté à l'année c'est 1,2To de donnée qui ne passerons pas dans les tuyaux.

Sur une autre plate-forme nous avons utilisé un CDN pour prendre un charge la diffusion des images. Le service de CDN nous facture environs 25ct d'euro le Go transporté. On peux donc spéculé que un gain de 1,2To représente donc 300€.

Je rappel que ceci est totalement spéculatif et sur les seules donnée de voici.fr, attention.

Bad User Karma

Je viens de prendre conscience que j'avais saturé mon filesystem et que en conséquence le storage de voici.fr fait plus de 9,9 Go.

L'exorciste reste valide, mais partiel.

aucun commentaire

mercredi, octobre 28 2009

Voici.fr preuve par l'image de l'intérêt de l'optimisation web cache et des performance des reverses proxys

Par Charles-Christian Croix le mercredi, octobre 28 2009, 10:02 - Actu Pro

Suite à mes articles sur la configuration eZ publish pour l'utilisation des caches web, sur l'optimisation des reverse proxy squid j'ai tenté de faire la démonstration de l'intérêt de l' optimisation web cache et des performance des reverses proxys. Je vais apporter quelques preuve de plus dans cet article.

Tenir les versions des logiciels à jours

L'optimisation de ces web cache et la performance des reverses proxys passe tout simplement pas la mise à jour régulière du système et des logiciels. Dans l'exemple ci dessous le gains de performance est flagrant entre une configuration Debian Sarge avec Squid 2.5 et une configuration Debian Etch avec Squid 2.6. Au mois d'octobre 2008 le taux d'utilisation du cpu par le système à chuté, un goulot d'étranglement à été supprimé.

Soigner la configuration eZ et apache pour squid

Suite à la mort de Michael Jackson Gala.fr et principalement Voici.fr ont connu un très fort pic de charge. Durant cette épisode d'audience intense nous avons poussé en production différente optimisation que nous avions précédemment préparé. Ces optimisations porte sur la configuration de eZ Publish 4 et de Apache pour l'utilisation des caches web. L'effet principale étant obtenue en allongeant le temps de rétentions des images et en instaurant la compression pour les fichiers css et javascript.

Affiner la configuration système des serveurs squid

Une configuration optimum des squid passe également par une adaptation du système à leur mission de reverse proxy tel que nous l'avons réalisé récemment. Le résultat est la et guère discutable pour un charge CPU légèrement supérieur nous desservons plus de client et stockons plus d'objet ce qui conduit à une plus faible sollicitation des frontaux.