Archives pour l'étiquette eZ publish

L’internet bug a Prisma Presse

Je ne suis pas le seul à partir. 24 des 26 personnes composants la DSI Internet de Prisma Presse partent également. En effet la quasi totalité des personnes assurant l’activité technique de l’internet dans cette entreprise ont souscrit au plan de départ volontaire ouvert dans le cadre d’un plan de sauvegarde de l’emplois.

Développeur, Administrateur système et réseau, Architecte Web, Chef de Projet, Expert SEO, Assistante, Responsable d’application, Chef de Projet Technique et même le Responsable de service on adhéré à ce plan. Cette unanimité a souhaiter partir de la part de personne au cœur d’une activité d’avenir pour l’entreprise soulève forcément beaucoup de question. Il ne m’appartiens pas d’expliquer comme la direction de Prisma Presse à laisser ceci ce produire. Un professeur d’HEC écrira peut être un mémoire de management sur ce plan ou alors un sociologue étudiera cette dynamique de groupe qui conduit tout un service à préférer partir. Mais force est de constater que cette situation n’a jamais été désirée ou voulue de la part de l’entreprise. A mon humble avis la situation ainsi générée devrait induire au moins 20% de coût supplémentaire pour Prisma Presse dans son activité Internet et lui couter quelque point d’audience.

MySQL Innodb nouvelle notes de configuration et d’optimisation

Pour compléter une note précédente sur Innodb et UTF8 et le billet sur les premières notes de configuration et d’optimisation de MySQL Innodb voici quelques notes de configuration de MySQL supplémentaire et complémentaire avec le moteur de base de donnée Innodb. Note toujours valable _ pour toute solution d’hébergement ou architecture MySQL est dédier eZ Publish, Dotclear 2 et autre CMS.

INNODB_BUFFER_POOL_SIZE

  • Espace mémoire de mise en cache des bases de données.
  • Ne pas hésiter à allouer 80 ~ 90% de la mémoire disponible sur le serveur si celui ci est dédier DB
  • Dans la mesure du possible doit être légèrement supérieur en taille à /var/lib/mysql

INNODB_FLUSH_METHOD

  • Instruction de gestion des accès disque
  • CODE_FS par défaut, laisse à l’OS toute possibilité de gérer les accès selon ces principes. L’OS peux donc utilisé son propre cache qui viendrais ce superposer à celui de innodb
  • O_DIRECT informe l’OS d’écrire sans délai sans tenir compte de son cache.
  • A rapprocher de l’instruction gérant le scheduler de l’OS cf: /sys/block/sda/queue/scheduler

QUERY-CACHE

  • Concerne les instructions query_cache_limit, query_cache_size, query_cache_type
  • A utilise seulement en cas de requêtes uniforme et répétitive, inutile si celle ci sont déporter sur un memcache
  • Effacer dans ce cache et y réécrire impose un MUTEX et donc un lock de tout les thread.
  • A utilisé seulement si le gain d’utilisation VS lock mutex est positif, rarement le cas sur une architecture qui utilise du memcache

SINGLE-TRANSACTION

  • mysqldump single-transaction all-databases > dump.sql
  • Instruction –single-transaction determine que le dump est a réaliser dans le contexte de l’instant T (snapshot style)
  • Ne génère pas de lock, lecture, écriture toujours possible
  • Génère une charge en lecture. Charge quasi nul sur tout le contenue de base dumper est en mémoire
  • Génère une charge en écriture. Penser à écrire sur une FileSystem non sollicité.

MySQL Innodb notes de configuration et d’optimisation

Pour compléter une note précédente sur Innodb et UTF8 voici quelques notes de configuration de MySQL avec le moteur de base de donnée Innodb sous forme de checklist pour toute solution d’hébergement ou architecture MySQL est dédier eZ Publish, Dotclear 2 et autre CMS.

Utilisez le moteur Innodb

Forcer le moteur par defaut de stokage en InnoDB pour la création de toute nouvelle table sans spécification du moteur souhaité.

<span style="color: #808080; font-style: italic;">#</span> <span style="color: #808080; font-style: italic;"># Moteur par defaut de stokage, ici InnoDB parce que  Ez publish</span> <span style="color: #808080; font-style: italic;">#</span> default-storage-engine  = InnoDB

UTF8

Prévoir dès le départ l’encodage des base en UFT8

<span style="color: #808080; font-style: italic;">#</span> <span style="color: #808080; font-style: italic;"># Encodage UTF8</span> <span style="color: #808080; font-style: italic;">#</span> default-character-<span style="color: #007800;">set=</span>utf8 default-<span style="color: #007800;">collation=</span>utf8 <span style="color: #007800;">collation_server=</span>utf8_general_ci <span style="color: #007800;">character_set_server=</span>utf8 skip-character-set-client-handshake

Configurer l’écoute sur toute les interfaces réseaux

Ouvrir à un utilisation via le réseau sans limitation d’interface ou d’adresse.

<span style="color: #808080; font-style: italic;">#</span> <span style="color: #808080; font-style: italic;"># Instead of skip-networking you can listen only on</span> <span style="color: #808080; font-style: italic;"># localhost which is more compatible and is not less secure.</span> bind-address            = <span style="color: #808080; font-style: italic;">#skip-networking</span>

Optimisation tablespace

Prévoir le lancement du moteur innodb avec comme configuration un fichier tablespace par table. Cela va créé un fichier tablespace pour chaque table innodb et vous évitera d’avoir dans quelque mois un unique fichier tablespace de plusieurs giga octet impossible à manipuler.

<span style="color: #808080; font-style: italic;">#skip-innodb</span> innodb_file_per_table

Optimisation Log

Bloquer les log binaire qui consomme beaucoup d’espace disque et n’apporte pas de sécurité sur une plate-forme qui n’a pas de réplication Master / Slave MySQL.

<span style="color: #808080; font-style: italic;">#log_bin                        = /var/log/mysql/mysql-bin.log</span>

Optimisation innodb_buffer_pool_size

innodb_buffer_pool_size définie la taille de buffer mémoire que InnoDB utilise pour mettre en cache les données et les index de tables. Plus cette valeur est grand, et moins vous ferez d’accès disques. Sur un serveur dédiés, vous pouvez monter cette valeur jusqu’à 80% de la mémoire physique de la machine. Ne lui donnez pas une valeur trop grande, car cela peut engendrer l’utilisation de mémoire sur le disque par votre serveur (swap).

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

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 <span style="color: #ff0000;">9</span>

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:

<span style="color: #00007f;">LogFormat</span> <span style="color: #7f007f;">'&quot;%r&quot; %{outstream}n/%{instream}n (%{ratio}n%%)'</span> deflatelog

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

<span style="color: #00007f;">CustomLog</span> /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.

<span style="color: #7f007f;">&quot;GET /dotclear/themes/default/js/jquery.cookie.js HTTP/1.1&quot;</span> <span style="color: #ff0000;">451</span>/<span style="color: #ff0000;">994</span> <span style="color: #66cc66;">&#40;</span><span style="color: #ff0000;">45</span>%<span style="color: #66cc66;">&#41;</span>

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

Voici.fr résultat d’optimisation des images

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.