Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

Jouer à cache cache pour aller à toute vitesse

Tour d'horizon des solutions de cache Open Source en environnement LAMP.

Problématique :

tortue-fusée.jpgLes prix des serveurs, ce n'est pas un scoop dépendent des performances de ceux-ci. Or quand on gère un parc de plusieurs centaines de machines, chaque serveur à une fonction dédiée : serveur web (apache), base de données (mysql), de fichiers, de cache, d'email, ... Cela permet de conserver une simplicité dans la maintenance et ram.jpgsurtout d'adapter les caractérisques aux besoins : de la RAM et des disques rapides pour les BDD, etc. Ces dernières années, l'apparition des web service impose des temps de réponses de plus en plus court pour ne pas pénaliser des utilisateurs. D'un autre côté le prix de la RAM a considérablement baissé au contraire de la performance des disques où pour obtenir des vitesses d'accès au données il faut débourser de plus en plus. Il apparaît donc évident que nos logiciels doivent de plus en plus passer par des systèmes de cache en mémoire vive et limiter les accès au disque dur.

Principe :

N'accéder à une donnée située un disque qu'une seule fois sinon c'est gâcher ! Or gâcher, c'est Muda et Muda c'est pas Lean !

Tour d'horizon par type de données (classé par impact sur l'équipe de développeurs) :

  • Cache opt-code

Quand vous développez avec un language interprété comme PHP, un point noir ralentissant le temps de réponse de l'applicatif se situe dans le besoin pour du serveur web (Apache) d'accéder et d'interpréter à chaque requète les fichiers PHP. C'est souvent un point critiqué et critique des framework PHP (Synfony et Zend) ! Il existe donc des solutions comme EAccelerator ou X-cache. Ces softs mettent en cache une version compilée des fichiers PHP ce qui permet de gagner du temps. J'ai réalisé une étude sur le sujet l'année dernière qui montrait un gain de 40% ! Ce genre d'optimisation n'a aucun impact sur les méthodes de développement et apporte un gain significatif.

  • Cache de fichiers statiques

De plus en plus de fichiers statiques sont chargés sur les sites. On entent par fichier statique des fichiers javascript, css, images, ... Les interfaces de plus en plus conviviales du web 2.0 proposent des effets visuels certes sympa mais qui alimentés par des librairies javascript parfois lourdes donc longue à charger. Comme ces fichiers changent rarement et sont souvent chargées, l'idée est de les monter en mémoire et de ne plus accéder au disque. Un serveur de proxy cache comme Squid permet de faire cela. Là encore, cela ne changent pas les habitudes des développeurs. Il faut pense à placer les fichiers sur un domaine différent pour faciliter la mise en place.

  • Cache de page dynamique

Pour ne pas avoir à éxécuter toutes les requètes en base de données tant qu'une modification n'a pas été apportée, il est fréquent de placer le contenu d'une page en cache. Memcached est une solution pour placer variables et contenu en mémoire vive. Cela permet de placer des données fréquents utilisées (configuration, ...) ou la home d'un site. Là encore cela court-circuite des étapes longue et couteurse en temps. L'impact pour le développeur est pas nulle il devra prendre conscient de l'intérêt du cache. Le fonctionnement en développement (sans cache) et en production (avec cache) peut être sensiblement différent. Il conviendra donc de tester tous les cas d'utilisation ce qui peut ralentir les recettes et complexifie légèrement le développement.

  • Cache de base de données

Il y a plusieurs possibilités. Les plus simples sont de mettre en cache (dans memcache par exemple) le tableau de résultat d'une requête. La librairie ADODB, qui est une somme de classes PHP permettant de se connecter sur plusieurs type de base de données relationnelles. Pour pousser plus loin il est parfois préférable de monter en mémoire le contenu intégrale d'une ou plusieurs tables et de faire des manipulations sur le jeu de données pour exclure des enregistrements qu'on ne souhaiterait pas retourner. L'expertise pour savoir quelle méthode est la plus adaptée est déjà plus avancée. Pour les requêtes de type "full text", il conviendra d'utiliser un moteur d'index (de recherche). Les solutions comme Sphinx, Lucene Sol'R sont parfaitement adaptées pour des usage intensif de ce genre de requêtes. Elles gèrent des caches mémoires en fonction de l'utilisation des données ce qui garantie une efficacité dans les temps de réponses. De plus, elles peuvent être distribuée et redondée garantissant une évolution sans contrainte. Il suffit de plugger un nouveau serveur et c'est parti. Les index sont des sortes de bases de données non relationnelle c'est pour cela qu'elles sont plus évolutive (scalable). Une nouvelle tendance de 2009 est justement la vague NoSQL. CoucheDB par exemple est une solution de stockage de données "à plat" (une seule table avec des entrées appelées documents). Il existe plusieurs solutions qui ne sont pas encore dominant car pas suffisamment mature. Ces bases de données vont changer radicalement la façon de développer et pour le coup l'impact pour une équipe de développement est très fort.

Projection pour 2010 :

Puisque c'est la fin de l'année, voici ma vision pour 2010. A mon sens, les bases de données NoSQL ne l'emporterons que celles sauront être efficace en recherche full text. Il y a un enjeu considérable à présenter de manière efficace les données texte (courbe de buzz d'un tag, analyse sémantique et du sentiment) parmi les contributions du web 2.0.

 

Les commentaires sont fermés.