Archives pour l'étiquette Geo.fr

Voici.fr : Optimisation d’un site eZ Publish 4 pour l’utilisation des caches web

Introduction au cache web

Documentation préalable

Si la gestion de cache web est pour vous une notion vague je vous invite à lire cette excellente documentation de Mark Nottingham en français nommée tutoriel de la mise en cache pour les auteurs Web et les webmestres. Vous y apprendrez tout sur les caches de navigateurs les caches de serveurs mandataires nommé proxy et reverses proxy ainsi que tout sur la configuration des en tête ou header du protocole HTTP nécessaire tel quel documenté dans la rfc 2616 section Caching in HTTP

La chaîne des caches.

Les caches web forme sont présent sur tout la chaîne de distribution entre vote site web et l’internaute. Cette chaîne peux être complexe ou très simple mais vous n’en maitrisez pas la structure. Imaginons le cas d’une chaîne complexe, quel sont les chainons ?

  1. Votre serveur web apache
  2. Un reverse proxy en amont de votre serveur sur la même architecture
  3. Un proxy chez le FAI dont dépendant la connexion de l’internaute
  4. Un second proxy en entré du réseau Lan de l’internaute (typique d’un réseau d’entreprise, école, université etc..)
  5. Le cache navigateur du logiciel client utilisé pour l’internaute pour consulté votre site.
  6. Et enfin l’internaute.

Entre votre serveur apache et l’internaute nous avons ici 4 étapes intermédiaires qui sont autant de cache sur la chaîne de distribution. Savoir tirer partie de ces caches est important pour économiser les ressources de votre hébergement et produire un site à l’affichage rapide et sans erreur (qualité indispensable au succès).

L’enjeux est important :

  • Les économies réalisables sont immenses. Dans l’exemple 4 services de cache peuvent répondre à l’internaute avant que votre propre serveur soient consulté.
  • Les dangers sont immenses. Dans l’exemple 4 services de cache peuvent répondre à l’internaute, avant votre propre serveur, une information obsolète que vous n’avez pas maitrisé.

 

Les acteurs: développeur et administrateur système LAMP[1]

La gestion des caches web pour une site eZ publish est le sujet d’exemple de la collaboration nécessaire entre les développeur ou responsable d’application et les responsable d’hébergement ou administrateur système.

Dans le cas ou vous ne maitrisez pas votre hébergement directement, quelque soit la raison, il est nécessaire de vous attacher les compétences de l’administrateur système en charge de votre serveur web.

 

Tâche à la charge du developpeur ou responsable d’application eZ Publish

Le développeur, ayant la haute main sur le code de son application, ce doit pour une parfaite configuration de la chaine des caches web de configurer son instance de eZ Publish pour cela. A cette fin il s’attachera à comprendre les paramètres de configuration de la section HTTPHeaderSettings du fichier site.ini[2]

Header HTTP par defaut de eZ publish

Voici tel que ce présente cette section HTTPHeaderSettings par défaut sans modification après une installation de eZ publish 4.2. Cette configuration par défaut désactive toute possibilité de cache web.

<span style="color: #66cc66;">[</span>HTTPHeaderSettings<span style="color: #66cc66;">]</span> <span style="color: #808080; font-style: italic;"># Enable/disable custom HTTP header data.</span> CustomHeader<span style="color: #66cc66;">=</span>disabled   <span style="color: #808080; font-style: italic;"># Only apply custom headers for anonymous users</span> OnlyForAnonymous<span style="color: #66cc66;">=</span>disabled   <span style="color: #808080; font-style: italic;"># Header list. Contains all HTTP which should override standard ones.</span> HeaderList<span style="color: #66cc66;">[</span><span style="color: #66cc66;">]</span> HeaderList<span style="color: #66cc66;">[</span><span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span>Cache<span style="color: #66cc66;">-</span>Control HeaderList<span style="color: #66cc66;">[</span><span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span>Pragma HeaderList<span style="color: #66cc66;">[</span><span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span>Expires   <span style="color: #808080; font-style: italic;"># Default Cache-Control header</span> <span style="color: #808080; font-style: italic;"># HTTP Headers are specified using the following format :</span> <span style="color: #808080; font-style: italic;"># &lt;HTTP header&gt;[&lt;eZ Publish path|module{/view}&gt;]=&lt;value&gt;{;&lt;depth&gt;{;&lt;level&gt;}}</span> <span style="color: #808080; font-style: italic;">#</span> <span style="color: #808080; font-style: italic;"># Example :</span> <span style="color: #808080; font-style: italic;"># # Set Pragma HTTP header to no-cache for whole site, except /news, and 2 levels below news.</span> <span style="color: #808080; font-style: italic;"># Pragma[]</span> <span style="color: #808080; font-style: italic;"># Pragma[/]=no-cache;2</span> <span style="color: #808080; font-style: italic;"># Pragma[/news]=;2;0</span>   <span style="color: #808080; font-style: italic;"># Cache-Control values are set directly</span> Cache<span style="color: #66cc66;">-</span>Control<span style="color: #66cc66;">[</span><span style="color: #66cc66;">]</span> Cache<span style="color: #66cc66;">-</span>Control<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span><span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span>no<span style="color: #66cc66;">-</span>cache<span style="color: #66cc66;">,</span> must<span style="color: #66cc66;">-</span>revalidate   <span style="color: #808080; font-style: italic;"># Pragma values are set directly</span> Pragma<span style="color: #66cc66;">[</span><span style="color: #66cc66;">]</span> Pragma<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span><span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span>no<span style="color: #66cc66;">-</span>cache   <span style="color: #808080; font-style: italic;"># Expires specifies time offset compared to current time</span> <span style="color: #808080; font-style: italic;"># Default expired 2 hours ago ( no caching )</span> Expires<span style="color: #66cc66;">[</span><span style="color: #66cc66;">]</span> Expires<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span><span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span><span style="color: #cc66cc;">-7200</span>

Header HTTP de eZ publish pour Voici.fr

Sur Voici.fr nous avons fait les choix suivants:

  • Un cache à 5 minutes pour la home page afin d’être réactif tout en utilisant le cache web. Cette période courte offre la possibilité d’avoir une actualisation de site fréquente entre deux visites pour l’internaute tout en lissant le nombre de requêtes à nos serveur durant une même visite.
  • Pour les têtes de rubriques, flux rss et autre sitemap nous avons porté le temps de cache à 15 minutes
  • Pour le compte utilisateur et les fonctions communautaire nous avons configuré un temps de cache négatif en plus d’une instruction pragma no cache afin d’être actualisé à chaque affichage.

Nos paramètre sont donc les suivants (extrait):

<span style="color: #66cc66;">[</span>HTTPHeaderSettings<span style="color: #66cc66;">]</span> CustomHeader<span style="color: #66cc66;">=</span>enabled Cache<span style="color: #66cc66;">-</span>Control<span style="color: #66cc66;">[</span><span style="color: #66cc66;">]</span> Cache<span style="color: #66cc66;">-</span>Control<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span><span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span><span style="color: #000000; font-weight: bold;">public</span><span style="color: #66cc66;">,</span>must<span style="color: #66cc66;">-</span>revalidate Cache<span style="color: #66cc66;">-</span>Control<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>potins<span style="color: #66cc66;">-</span>people<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span><span style="color: #000000; font-weight: bold;">public</span><span style="color: #66cc66;">,</span>must<span style="color: #66cc66;">-</span>revalidate <span style="color: #66cc66;">...</span> Cache<span style="color: #66cc66;">-</span>Control<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>communaute<span style="color: #66cc66;">/</span>espace<span style="color: #66cc66;">-</span>prive<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span>no<span style="color: #66cc66;">-</span>cache<span style="color: #66cc66;">,</span>must<span style="color: #66cc66;">-</span>revalidate Cache<span style="color: #66cc66;">-</span>Control<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>rss<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span><span style="color: #000000; font-weight: bold;">public</span><span style="color: #66cc66;">,</span>must<span style="color: #66cc66;">-</span>revalidate Cache<span style="color: #66cc66;">-</span>Control<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>prismaatom<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span><span style="color: #000000; font-weight: bold;">public</span><span style="color: #66cc66;">,</span>must<span style="color: #66cc66;">-</span>revalidate   Expires<span style="color: #66cc66;">[</span><span style="color: #66cc66;">]</span> Expires<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span><span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span><span style="color: #cc66cc;">300</span> Expires<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>potins<span style="color: #66cc66;">-</span>people<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span><span style="color: #cc66cc;">900</span> <span style="color: #66cc66;">...</span> Expires<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>communaute<span style="color: #66cc66;">/</span>espace<span style="color: #66cc66;">-</span>prive<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span><span style="color: #cc66cc;">-7200</span> Expires<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>rss<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span><span style="color: #cc66cc;">900</span> Expires<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>prismaatom<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span><span style="color: #cc66cc;">900</span>   Pragma<span style="color: #66cc66;">[</span><span style="color: #66cc66;">]</span> Pragma<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span><span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span> Pragma<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>potins<span style="color: #66cc66;">-</span>people<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span> <span style="color: #66cc66;">...</span> Pragma<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>communaute<span style="color: #66cc66;">/</span>espace<span style="color: #66cc66;">-</span>prive<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span>no<span style="color: #66cc66;">-</span>cache Pragma<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>rss<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span> Pragma<span style="color: #66cc66;">[</span><span style="color: #66cc66;">/</span>prismaatom<span style="color: #66cc66;">]</span><span style="color: #66cc66;">=</span>

Hearder HTTP Home page Voici.fr

Header HTTP de la home page de Voici.fr

 

Taches a la charge du responsable d’hébergement ou administrateur système.

L’administrateur système n’est pas exempt de tache. En tant que responsable de l’hébergement et donc de la configuration serveur il doit mettre en oeuvre la couche LAMP. D’un point de vue système les besoins de eZ Publish sont important au point que la limite entre l’application et le système m’apparais bien flou, surtout si vous visez la haute performance.

Concernant apache il est nécessaire de le configurer avec un vhost comportant un certain nombre de paramètre précis. Entre autre l’utilisation du mod_rewrite est systèmatique avec eZ Publish. En effet tout appel de page doit ce faire au travers du index.php de l’application et uniquement par lui. Tout autre appel de ressources devant être appelé directement et de façon statique.

Le Vhost apache eZ Publish

De ce fait le vhost par défaut de eZ publish tel qu’il est recommandé dans la documentation de la version 4 ressemble à ceci :

<span style="color: #00007f;">NameVirtualHost</span> <span style="color: #ff0000;">128.39</span><span style="color: #ff0000;">.140</span><span style="color: #ff0000;">.28</span>   &lt;VirtualHost <span style="color: #ff0000;">128.39</span><span style="color: #ff0000;">.140</span><span style="color: #ff0000;">.28</span>&gt;     &lt;Directory /var/www/example&gt;         <span style="color: #00007f;">Options</span> <span style="color: #0000ff;">FollowSymLinks</span>         <span style="color: #00007f;">AllowOverride</span> <span style="color: #0000ff;">None</span>     &lt;/Directory&gt;       &lt;IfModule mod_php5.c&gt;         php_admin_flag safe_mode <span style="color: #0000ff;">Off</span>         php_admin_value register_globals    <span style="color: #ff0000;">0</span>         php_value magic_quotes_gpc  <span style="color: #ff0000;">0</span>         php_value magic_quotes_runtime  <span style="color: #ff0000;">0</span>         php_value allow_call_time_pass_reference <span style="color: #ff0000;">0</span>     &lt;/IfModule&gt;       <span style="color: #00007f;">DirectoryIndex</span> index.php       &lt;IfModule mod_rewrite.c&gt;         <span style="color: #00007f;">RewriteEngine</span> <span style="color: #0000ff;">On</span>         <span style="color: #00007f;">RewriteRule</span> content/treemenu/? /index_treemenu.php <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">Rewriterule</span> ^/var/storage/.* - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">Rewriterule</span> ^/var/<span style="color: #66cc66;">[</span>^/<span style="color: #66cc66;">]</span>+/storage/.* - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">RewriteRule</span> ^/var/cache/texttoimage/.* - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">RewriteRule</span> ^/var/<span style="color: #66cc66;">[</span>^/<span style="color: #66cc66;">]</span>+/cache/texttoimage/.* - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">Rewriterule</span> ^/design/<span style="color: #66cc66;">[</span>^/<span style="color: #66cc66;">]</span>+/<span style="color: #66cc66;">(</span>stylesheets|images|javascript<span style="color: #66cc66;">)</span>/.* - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">Rewriterule</span> ^/share/icons/.* - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">Rewriterule</span> ^/extension/<span style="color: #66cc66;">[</span>^/<span style="color: #66cc66;">]</span>+/design/<span style="color: #66cc66;">[</span>^/<span style="color: #66cc66;">]</span>+/<span style="color: #66cc66;">(</span>stylesheets|images|javascripts?<span style="color: #66cc66;">)</span>/.* - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">Rewriterule</span> ^/packages/styles/.+/<span style="color: #66cc66;">(</span>stylesheets|images|javascript<span style="color: #66cc66;">)</span>/<span style="color: #66cc66;">[</span>^/<span style="color: #66cc66;">]</span>+/.* - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">RewriteRule</span> ^/packages/styles/.+/thumbnail/.* - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">RewriteRule</span> ^/favicon\.ico - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #00007f;">RewriteRule</span> ^/robots\.txt - <span style="color: #66cc66;">[</span>L<span style="color: #66cc66;">]</span>         <span style="color: #adadad; font-style: italic;"># Uncomment the following lines when using popup style debug.</span>         <span style="color: #adadad; font-style: italic;"># RewriteRule ^/var/cache/debug\.html.* - [L]</span>         <span style="color: #adadad; font-style: italic;"># RewriteRule ^/var/[^/]+/cache/debug\.html.* - [L]</span>         <span style="color: #00007f;">RewriteRule</span> .* /index.php     &lt;/IfModule&gt;       <span style="color: #00007f;">DocumentRoot</span> /var/www/<span style="color: #00007f;">example</span>     <span style="color: #00007f;">ServerName</span> www.<span style="color: #00007f;">example</span>.com     <span style="color: #00007f;">ServerAlias</span> admin.<span style="color: #00007f;">example</span>.com &lt;/VirtualHost&gt;

Or si le mod_rewrite et les expression régulières ne vous sont pas trop inconnues vous constaterez que tout appel d’image, de css ou de javascript pour le design du site comme ceux du contenue publié bénéficie d’exclusion à la régle de redirection final vers le index.php.

Du fait de ces exclusion les image, css et javascript sont directement fournit par apache sans que les paramètres de configuration des headers du protocole http tel que configuré par le développeur ou responsable d’application ne soit pris en compte.

Le Vhost apache eZ Publish pour Voici.fr

Afin de configurer les headers du protocole HTTP en réponse à chaque requête image, css et javascript il est nécéssaire de mettre en oeuvre des mécanismes propre à apache. L’enjeux est d’importance au regard du poids de l’image dans la volume total d’une page web.

 

Mod_expires pour Voici.fr, ne jeter plus les images après usage

Afin de configurer les header HTTP avec les instructions de mise à cache nous avons utilisé le mod_expire en précisant pour chaque type mime un temps de vie. Dans le cas de notre site nous avons inclus le block suivant dans le vhost apache de voici.fr.

&lt;IfModule mod_expires.c&gt;                 <span style="color: #00007f;">ExpiresActive</span> <span style="color: #0000ff;">on</span>                   <span style="color: #00007f;">ExpiresByType</span> text/css <span style="color: #7f007f;">"access 1 days"</span>                 <span style="color: #00007f;">ExpiresByType</span> application/x-javascript <span style="color: #7f007f;">"access 1 days"</span>                 <span style="color: #00007f;">ExpiresByType</span> text/javascript <span style="color: #7f007f;">"access 1 days"</span>                 <span style="color: #00007f;">ExpiresByType</span> image/gif <span style="color: #7f007f;">"access 1 days"</span>                 <span style="color: #00007f;">ExpiresByType</span> image/jpeg <span style="color: #7f007f;">"access 1 days"</span>                 <span style="color: #00007f;">ExpiresByType</span> image/png <span style="color: #7f007f;">"access 1 days"</span>         &lt;/IfModule&gt;

Hearder HTTP logo Voici.fr

Header HTTP du logo de Voici.fr

 

Mod_gzip pour Voici.fr, le régime des css

Dans le cas de voici.fr nous recherchions à limiter la sollicitation de nos serveurs mais également bande passante utilisée, l’utilisation des headers HTTP est une solution efficace et performante.

Mais nous avons constaté un autre phénomène lié à la vie médiatique du site. La dynamique d’un site comme voici.fr impose des modifications de style, de présentation et de format en continue pour ce distingué de la concurrence répondre au demande SEO ou tout simplement faire « vivre » le site. Une telle vie trépidante à conduit à un hyper croissance des fichiers css.

A chaque nouvelle charte graphique ou mise à jour les fichiers css grossissaient de nouvelle instruction de design. De l’habillage original les têtes de rubrique on commencé à changé, puis le format des articles, plus les formats des videos etc.. D’un css A nous avions maintenant en plus A1 pour les têtes de rubrique, A2 pour les articles, A3 pour les vidéos et ainsi de suite. Chaque css comportant ça propre présentation de balise html courante, chaque webdesigner a ajouter sa patte sans toucher à ce qui a été réalisé précédemment. Un final, dans un tel cas, le fichier css peux atteindre des tailles respectable de l’ordre de 500Ko[3].

Notre solution le mod_gzip qui permet à apache avant de délivrer un fichier css de le zipper. Nous l’avons configuré de façon à ne travailler que sur des fichiers de taille pertinente (ni top gros ni trop petit). Nous l’avons configuré pour qu’il ne zippe que les fichiers texte du type mime css ou javascript.

&lt;IfModule mod_gzip.c&gt; 		mod_gzip_on Yes 		mod_gzip_can_negotiate Yes 		mod_gzip_static_suffix .gz 		<span style="color: #00007f;">AddEncoding</span> gzip .gz 		mod_gzip_update_static No 		mod_gzip_command_version <span style="color: #7f007f;">'/mod_gzip_status'</span> 		mod_gzip_temp_dir /tmp 		mod_gzip_keep_workfiles No 		mod_gzip_minimum_file_size <span style="color: #ff0000;">500</span> 		mod_gzip_maximum_file_size <span style="color: #ff0000;">1000000</span> 		mod_gzip_maximum_inmem_size <span style="color: #ff0000;">60000</span> 		mod_gzip_min_http <span style="color: #ff0000;">1000</span> 		mod_gzip_handle_methods GET POST   		mod_gzip_item_include mime ^text/css$ 		mod_gzip_item_include mime ^text/javascript$ 		mod_gzip_item_include mime ^application/x-javascript$   		mod_gzip_dechunk Yes 		mod_gzip_add_header_count Yes 		mod_gzip_send_vary Yes 	&lt;/IfModule&gt;

Poids Css voici.fr

Poids des css dans la home de Voici.fr

 

Conclusion en forme de scénario

Un internaute consultant le site voici.fr sollicitera nos serveurs pour l’intégralité des éléments de la première page appelée. Dès le seconde page les images et fichiers css du desing du site ne seront plus appelés, les instructions des hearder http donnant l’autorisation au navigateur de ce fournir dans son cache pour ces éléments la précisément, ceci durant 24 heures à partir de l’heure ou il à accédé pour la première fois à l’élément.
Concernant le code html constituant la page web il sera demandé à nos serveur à chaque nouvelle page. Mais si l’internaute retourne sur la home page durant les 5 minutes de temps de vie du cache le navigateur, tout comme pour les images, ce fournira sans son cache sans consulté les serveurs.
Passé 5 minutes toute nouvelle demande de la home page sur le navigateur généra un appel aux serveurs pour le code html, mais pas pour les images.

Il ne vous reste plus qu’a concevoir un architecture de reverse proxy en amont de vos serveurs pour garder en cache toute ces informations et éviter durant les périodes de temps de vie définir de sollicité vos serveurs.

Notes

[1] Linux Apache Mysql Php, pas de windows ici

[2] Attention a la logique de surcharge des fichier ini propre à eZ pulbish

[3] « Que ceux qui aiment Dreamweaver, les popups, les iframes, les Gifs, se retirent »

Comment connaitre l’audience des grands sites web de presse français ?

L’audience et la page vue

Je vous parle parfois de forte audience sur voici.fr ou gala.fr par exemple au moment de la mort de Mickael Jaskson. J’évoque des fortes charge absorbé avec l’aide de NAS, squid et autre. Mais comme être sur de ce que j’avance ? Comment comparer avec votre architecture ? Est ce que ce les techniques ou solution que je dis utiliser sont si efficace ? Et les autres ils bourrent à combien sur leurs babasse ?

Bref « il est gros à quel point ton site ? »

Continuer la lecture de Comment connaitre l’audience des grands sites web de presse français ?

Voici.fr et Gala.Fr utilisant eZ Publish ont survécu à la mort de Michael Jackson

La mort de Michael Jackson submerge Internet

La mort de Michael Jackson à enflammé le web mondial au point que certains services et sites ont eu du mal à soutenir l’audience comme le rapporte TF1, Le Parisien ou encore Le monde Informatique.

Même pas mal !

A force d’un travail constant de recherche de performance tant par la remonté d’information, de log et de question aux développeurs que par l’étude de configuration fine des reverse proxy squid, des apaches et des mysql nous avons encaissé la vague médiatique de la mort de Michael Jackson

Les records d’audience avec eZ publish

Je vous parlais récemment du score fait par un de nos sites en eZ 4. Or ce site est hébergé sur une plate-forme d’hébergement mutualisée de notre conception (ou presque). Ce jour de score la plate-forme entière à également battue son record : lundi 22/06/2009 1 397 524 pages vues

Depuis avec la mort de Michael Jackson nous avons eu deux nouveaux record d’audience sur la même plate-forme. le vendredi 26/06/2009 avec 1 623 589 de pages vue et le lundi 29/06/2009 avec 1 829 122 de pages vues.

Attention, je parle bien de pages vue pour l’ensemble de la plate-forme qui accueil en toute et pour tout 3 sites eZ 3.x, 3 sites eZ 4.x et une poignet de blog WP. Certains sites font 2K page vues en 24h d’autre 600K. Seul deux de ces sites on connue le pic d’audience généré par la mort de Michael Jackson.

Tenir cette charge avec eZ

Même pas mal. Cette audience est événementielle et s’applique sur un nombre de page / article réduit ce qui ne consomme pas des ressources sur l’intégralité de la plate-forme. Les pages en question n’ont pas à être fréquemment calculé par eZ car elle ne change pas beaucoup. De ce fait les frontaux et base de donnée sont sollicité mais pas de façon proportionnel à la monté de l’audience. Par contre les reverse proxy sont eux très fortement sollicité pour distribué massivement les quelques pages demandées (60 Mb/s en sortie). La configuration des trois serveurs squid en mode reverse proxy à été essentiel. L’infrastructure réseau doit être capable d’accepter un grand nombre de connexion tcp (je pense au routeur et répartiteur de charge). Dans un cas la bande passante est passé de 68Mb/s à 170Mb/s en cinq petites minutes avec l’effet slash dot de google actu et yahoo actu !

170MbsDeBP.jpg

PageVuePlateForme.jpg

SlashDotAvecYahooActu.jpg

Comment voici.fr, gala.fr, geo.fr, femmeactuelle.fr en eZPublish utilisent le StaleCache et une architecture NAS

Second couche

Pierre Jean Duvivier, responsable du département WebFactory de EditPress n’en fini pas de revenir sur sa terrible expérience avec Ez Publish 3.x et les raisons de son abandon par EdiPress. Revenir car déjà le propos à déjà été exposé par ses soins dans un article nommé EzPublish : l’enfer du devoir article que j’ai un peu commenté en exposant ma propre vision des problématiques soulevé par le choix d’eZ.

Je trouvais déjà la première condamnation de eZ sans nuance alors que le respect de quelques préceptes de dev permet de faire des choses bien plus que honorable avec eZ. Mais bon chacun son vécu et pour avoir transpiré à trouver des solutions d’architectures capable de soutenir l’audience je compatissais. Par contre la nouvelle et seconde couche passé par Pierre Jean Duvivier me semble un peu injuste car depuis 18 mois l’eau à couler sous les ponts. Un peu car la conception d’architecture pour eZ reste quelque chose de peu documenté et qui repose sur des connaissance quasi chamanquie.

eZ publish assure que le partage de donnée entre serveur dans une configuration multi-frontaux est prévus. Or dans la pratique on trouve vite des limites à cela. Je me permet de me cité moi même ^_^.

Dans le cas d’un site eZ avec du contenu dynamique la limite technique est de 30000 VU / 24h avec le partage d’information via NFS. Au delà de cette limite différent « bug » apparaisse qui vienne défigurer le contenue du site (bug wilcard, Bug NULLNULL, Perte cache block)

Dans le cas d’un site eZ avec du contenu dynamique la limite technique est de 35000 VU / 24h avec le partage d’information via le mode cluster dans une base de donnée Innodb/Mysql. Au delà de cette limite les demandes d’accès exclusif au information trop nombreux au point de bloqué le fonctionnement de l’application.

Pour dépasser les 35000 VU / 24h la seul solution que nous avons trouvé est de localisé l’intégralité de l’application sur un unique serveur en mode filer. Le matériel ayant évolué, avec un serveur Bi-Cpu quadri-core de 3Ghz avec 8Go de RAM il est parfaitement possible de produire 95000 VU / 24h c.a.d 300K pages vues par 24h. Nous avons testé cette solution sur voici.fr et gala.fr en version eZ 3.10 avec à chaque fois une réussite total, une bonne stabilité et le dépassement des seuil de production précédent. Reste que dépendre d’un unique serveur n’est pas une chose très sécurisante quand à la scalabilité…..

J’ai testé personnellement en suite différente architecture pour arrivé sur cette base à une solution multifrontal. Le NFS pur depuis un serveur lambda étant à oublier j’ai testé les profiles d’architecture suivante en multi-frontal avec l’aide de mon hébergeur hors norme pour son aide en R&D

  • Un serveur lambda partageant en mode bloc un volume via iSCSI. Deux frontaux utilisant ce volument via le système de fichier OCFS2 qui gère les concurrences
  • Un SAN Dell EqualLogic en mode bloc un volume via iSCSI. Deux frontaux utilisant ce volument via le système de fichier OCFS2 qui gère les concurrences
  • Un SAN Dell EqualLogic en mode bloc un volume via iSCSI. Deux frontaux utilisant ce volument via le système de fichier GFS2 qui gère les concurrences

Nous n’avons pas retrouver le rapport stabilité / capacité de production que nous avions connue avec le principe du frontal unique. Nous avons constaté que eZ ouvre et verrouille énormément de fichier par instance rendant le partage d’information entre frontaux problématique. Nous avons même constaté des lock récursif ce qui nous à tous laisser dubitatif. La conclusion était terrible, plus nous ajoutions de frontaux plus les instances entrait en concurrence pour accéder à l’information.

Quand le sujet était évoqué auprès des gens de chez eZ la réponse était par forcement audible. Par contre il était amusant de faire toussé Paul Bogermans de eZ publish en lui posant la question.

Mais depuis les choses on évolué

Suite à un forte pression des utilisateurs des moyen on été investi par eZ Publish pour que soutenir plus facilement une forte audience. Ceci à eu pour résultat le patch StaleCache dont j’ai parlé en signalant qu’il signifiait peut être la fin des combats.

Précédemment la génération d’un fichier cache se faisait à invalidation du précédent fichier, à la demande, et par chaque process qui le requiert; entrainant de nombreuses concurrences d’accès (lock des fichiers dans var/…/ezmutex) et une grande surcharge sur le filesystem. Le nouveau système (StaleCache) se débarrasse intégralement de la gestion de la concurrence par locks. Le mécanisme consiste maintenant à fournir aux frontaux web l’ancienne version du fichier de cache jusqu’à ce que la nouvelle soient re-générée. Ce qui diminue grandement l’empilement des process sur le filesystem en garantissant la génération du fichier par un process unique.

J’ai testé le StaleCache mais malheureusement pas dans une config multi-frontal. Rien à redire, ceci me semble être un direction bien plus pérenne que précédemment. Si quelqu’un pouvait tester ce patch avec une architecture serveur lambda partageant en mode bloc un volume via iSCSI. Deux frontaux utilisant ce volument via le système de fichier OCFS2 qui gère les concurrences, avec une audience forte je serais heureux d’en connaître l’issue. Le StaleCache est arrivé trop tardivement pour nous pour que nous l’appliquions sur ce type d’ architecture , nous avons pris une autre direction.

NAS

Nous avons fait le choix d’utilisé un NAS avec le protocole NFS. Ben et les bug lier à NFS vous allez me dire. Et bien avec la puissance d’un NAS et certainement avec l’implémentation propriétaire du protocole NFS du fabriquant nous n’avons pas ces bugs, par contre l’addition est douloureuse et ceci n’a peu être justifié que par un l’utilisation de cette ressource par plusieurs sites et une audience global des plus forte avec 6,7 Millions de visiteurs unique et 18,7 millions de pages vue par mois (OJD Janvier 2009). Avec une moyenne d’utilisation de seulement 140 opération seconde sur ce NAS nous avons encore de belle perspective devant nous.

Et le  »StaleCache’ ? et bien nous l’utilisons sur nos sites peoples avec succès.

EzPublish : l’enfer du devoir.

l’enfer de J.Duvivier

Pierre Jean Duvivier, responsable du département WebFactory de EditPress reviens sur son expérience avec Ez Publish 3.x et ces raisons de son abandon par EdiPress.

Je le cite : En 7 ans d’expérience sur des projets internet, j’ai vécu le cauchemard de ma vie avec ce CMS.

Il explique bien les difficultés de eZ publish pour les sites web à forte audience. J’aime bien son expression pics de décachage qui correspond au tempête SQL que je rencontre et qui génère des lock de table en chaine avec l’utilisation du mode cluster de eZ 3.x. J’ai évoqué le sujet chez pwet sur son article à propose du eZ developer day à Paris le 17/04/2008

Je vous invite a en lire plus sur cette expérience de Ez publish pour des sites web média à fort trafic.

Sa seul modération pour Ezpublish est le suivante : Attention la version mise en oeuvre était eZpublish 3.8. De plus un Framework avait été posé devant masquant ainsi une partie des fonctionnalités d’eZpublish.

J’aimerais avoir des informations sur le framework posé devant. Si il surcharge la gestion de cache de eZpublish on peux difficilement blâmer ce dernier d’être peu performant.

Ma vision de la Problématique

Avoir un site hyper-réactif, au contenue dynamique, aux mises à jour quasi immédiate impose un partage d’information tout aussi immédiat, avec une information vivante et volatile impose la centralisation de cette information. Toute tentative de répartissions, de distribution engendre une latence, un besoin de contrôle et de vérification de cohérence, bref tout ce qui engendre du délais et donc le contraire de l’hyper-réactif.

Quelque exemple d’hyper-réactivité d’un site :
- Nombre de commentaire à jour pour chaque article sur la home page
- Commentaire immédiatement disponible
- Liste des articles de première page annoncé sur chaque pas d’un site
- Personnalisation a outrance (login, avatar, message interne etc..)

En conséquence que cette information ultra centralisé soit accessible entre un nombre de frontaux ou processus important engendre de façon exponentiel à l’audience des accès concurrentiel et conflictuel à la même information. On arrive à un point de l’état de l’art informatique qui n’est pas encore résolut de façon économique.

Mon expérience ce porte sur des sites eZpublish 3.9 et 3.10, hyper-réactif, qui impose l’utilisation d’ajax pour individualisé le contenu de chaque page ou presque, ceci quasiment en temps réel. Ces sites génère 7Millions de pages vues et 1 millions de visiteur unique par mois.

Dans le cas d’un site eZ avec du contenu dynamique la limite technique est de 30000 VU / 24h avec le partage d’information via NFS. Au delà de cette limite différent « bug » apparaisse qui vienne défigurer le contenue du site (bug wilcard, Bug NULLNULL, Perte cache block)

Dans le cas d’un site eZ avec du contenu dynamique la limite technique est de 35000 VU / 24h avec le partage d’information via le mode cluster dans une base de donnée Innodb/Mysql. Au delà de cette limite les demandes d’accès exclusif au information trop nombreux au point de bloqué le fonctionnement de l’application.

A ce seuil technique d’utilisation de eZ comme générateur de site web eZ publish n’a pas de réponse fiable et viable à 100%. La préconisation de eZ Publish, information recueillie au eZ Developper day Paris 2008 et confirmée a l‘Ez Conférence de Skien 2008 est l’utilisation d’un NAS dont le ticket d’entré est de 35K€ (plus les cout de maintenance et administration annuel). C’est cette solution qui a semble avoir été mise en œuvre par d’autre acteur de la presse pour leur sites web atteignant le seuil technique des 30 ou 35 Kvu /24h

Et encore, l’utilisation d’un NAS offre que plus de puissance et donc traitant le partage d’information plus rapidement diminue les risques de conflit d’accès sans pour autant l’éliminer. En effet un NAS partage l’information via des protocoles n’offrant pas l’exclusivité d’accès au fichier (NFS, SMB etc). En outre l’utilisation d’un NAS introduit un goulot d’étranglement dans l’architecture. En cas de défaillance de celui ci tout les sites web l’utilisant seront impacté.

L’opposer d’un contenu dynamique c’est le site statique. C’est justement la solution avancé par pwet sur le blog de smile dans l’article : eZ publish à très hautes performances.