wOueb by Romain DECKER / Another IT Guy Blog

Parmi toutes les optimisations possibles pour un blog, un site ou une application, on retrouve Memcached qui se positionne comme un système de cache d’objets distribué et non répliqué. Initialement développé par Danga pour Livejournal, c’est un outil open source qui est maintenant utilisé par de nombreux sites (Facebook, Youtube, mon blog, Flickr, etc.)

J’utilise Memcached sur le serveur de mon blog depuis quelques mois, et la différence avec/sans est assez flagrante.

Pour comprendre son utilité, je rappelle simplement que les temps d’accès à la mémoire vive d’un serveur sont nettement supérieurs à ceux d’un disque (nanosecondes VS millisecondes, cad un ratio compris entre 10 000 et 100 000).

C’est là que Memcached intervient. Il va créer des tableaux de données en RAM : cela va contribuer à réduire le nombre de fois qu’une même donnée stockée sur un périphérique de stockage mécanique est lue.

La principale chose à comprendre avec Memcached est qu’il s’agit d’un système d’usage général, et que les applications doivent être « conscientes » de sa présence. Ce n’est pas quelque chose de magique, qu’il suffit d’installer pour multiplier les performances par 10. Il faudra a minima installer un plugin si vous utilisez un CMS, voire repasser dans une partie du code.

Sous forme d’architecture client-serveur, Memcached se présente comme un démon qui écoute par défaut sur le port 11211. Le système créé des tableaux dont les clés de 250 octets pointent vers des valeurs qui peuvent avoir jusqu’à 1 Mo (mégaoctet). Si la quantité de mémoire allouée est pleine, les clés les plus anciennes sont supprimées (méthode Least Recently Used). Comme les données sont stockées en RAM, elles seront perdues si le serveur redémarre.

Il est possibles d’utiliser plusieurs instances Memcached. Par exemple, une application ABC peut mettre des données en cache sur 3 serveurs différents :

• memcached1.monappli.com
• memcached2.monappli.com
• memcached3.monappli.com

Chaque serveur sera autonome et ne communiquera pas avec ses voisins.

Il est possible de répliquer des instances Memcached, mais ceci est une autre histoire !

Un grand nombre de librairies clientes pour accéder à Memcached sont disponibles : C/C++, PHP, Java, Windows/.Net, Ruby, Perl, etc.

Performances : avec / sans Memcached sur un WordPress

Pour vérifier le gain de performances, j’ai utilisé un serveur de test, avec une installation de WordPress vierge. J’ai fait un test de charge avec ApacheBench, avec et sans Memcached activé.

Benchmark :

• WordPress sans Memcached : 8,75 requêtes / secondes,
• WordPress avec Memcached : 150 requêtes / secondes.

Nb : il s’agit d’une installation d’Apache2 avec un paramétrage par défaut sur une CentOS 5.5 32 bits, 1 vCPU 2 Ghz, 512 Mo de Ram.

En conclusion, Memcached est un élément non négligeable qu’il est bon d’intégrer dans la conception d’une application. Cependant, comme c’est une couche d’intégration supplémentaire, il faut faire en sorte que l’application soit consciente que système existe.

Je reviendrais plus tard sur l’installation de Memcached…

Saviez-vous que tous les 1ers avrils, l’IETF sortait une RFC un peu décalée ? Celle de 1996 est particulièrement sympa : The Twelve Networking Truths.

(1) It Has To Work.

(2) No matter how hard you push and no matter what the priority,
you can’t increase the speed of light.

(2a) (corollary). No matter how hard you try, you can’t make a
baby in much less than 9 months. Trying to speed this up
*might* make it slower, but it won’t make it happen any
quicker.

(3) With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead.

(4) Some things in life can never be fully appreciated nor
understood unless experienced firsthand. Some things in
networking can never be fully understood by someone who neither
builds commercial networking equipment nor runs an operational
network.

(5) It is always possible to aglutenate multiple separate problems
into a single complex interdependent solution. In most cases
this is a bad idea.

(6) It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.

(6a) (corollary). It is always possible to add another level of
indirection.

(7) It is always something

(7a) (corollary). Good, Fast, Cheap: Pick any two (you can’t
have all three).

(8) It is more complicated than you think.

(9) For all resources, whatever it is, you need more.

(9a) (corollary) Every networking problem always takes longer to
solve than it seems like it should.

(10) One size never fits all.

(11) Every old idea will be proposed again with a different name and
a different presentation, regardless of whether it works.

(11a) (corollary). See rule 6a.

(12) In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take
away.

Sympa non ?

Projet a lancé par les fondateurs de Kazaa et de Skype, Joost est un service permettant la distribution de programme de télévision et de vidéos sur Internet utilisant la technologie Peer-to-Peer.

J’avais parlé de Joost il y a 18 mois, et mon avis sur la question restait en suspens : je me demandais alors comment ils allaient pouvoir continuer dans la voie choisie, avec une application cliente, alors que les autres services de distribution vidéos en ligne utilisait un système de lecteur flash.

C’est début octobre que Joost a modifié son architecture : dorénavant un lecteur flash standard est utilisé pour visualiser les programmes.

Joost est passé au streaming avec un lecteur flash

A l’heure actuelle, Joost compte plus de 46 000 vidéos en ligne : ce chiffre paraît dérisoire comparé à Youtube ou Dailymotion, mais il faut garder à l’esprit que ce sont des programmes complets, et non des vidéos mises à disposition par d’autres internautes.

Plus d’informations sur le blog de Joost.

Application en ligne assez austère, SQL Designer est malgré tout un modèle d’ergonomie : elle vous permet de créer visuellement vos modèles de données dans votre navigateur.

Au menu des réjouissances :

• import de modèles existants (au format XML),
• export pour différents type de SGBD (MS SQL, PostgreSQL, Oracle, MySQL),
• manipulation des tables (création, édition, liaison, déplacement, etc.) par simple drag and drop,
• format imprimable,
• etc.

Vous pouvez tester et utiliser l’application en ligne, mais SQL Designer a pour vocation de s’installer sur votre propre serveur. En effet, il est possible de télécharger le code et de l’installer sur n’importe quel hébergement qui supporte le PHP.

Cet article est le premier d’une nouvelle rubrique traitant des architectures complexes des sites et applications à fort trafic.

Tout le monde connaît Wikipedia, l’encyclopédie en ligne qui totalise près de 8 millions d’articles dans plus de 200 langues (15 langues ont plus de 100 000 articles). Tous les projets Wikipedia, Wiktionary, WikiBooks, WikiNews, etc., sont soutenus et hébergés par la fondation Wikimedia.

Commençons par quelques chiffres sur cette plate-forme pour situer le contexte :

• Wikipedia est le 9ème site le plus plus consulté au monde selon Alexa,
• plus de 350 serveurs répartis dans 3 datacenters différents (Floride, Amsterdam, Séoul),
• près de 50 000 requêtes HTTP/seconde en pic, pour une moyenne de 27 000 requêtes HTTP/seconde,
• 2,2 Gbits/s de bande passante moyenne pour 3,7 Gbits/s en pic,
• en moyenne, 2 000 nouveaux articles et 200 000 edits quotidiens,
• 1,3 To de stockage pour les images (plus de 4 millions de fichiers),
• 25 Go de données dans MySQL,
• un nombre de mots avoisinant les 2,5 milliards,
• une croissance exponentielle : doublant tous les six mois en terme de visiteurs/trafic/serveurs.

Dans le second article de ce dossier, je détaillerai l’architecture, la répartition de l’effort informatique, ainsi que les astuces utilisées par Wikimedia pour garantir un service de qualité avec peu de serveurs.

Sources :

• Wikimedia Grid,
• Leon’s Weber project,
• Données Alexa,
• Wikipedia : Multilingual Statistics,
• Wikipedia Statistics,
• Wikipedia Datas.