500 000 opérations par seconde via Memcached

May 21, 2009

sun-ultrasparc-t2Je vous parlais il y a quelques mois d’un test de MySql qui avait permit de valider presque 80 000 requêtes SQL par seconde sur un seul serveur. Cette fois il s’agit d’un autre test, sur memcached. Outil indispensable pour gérer un système de cache distribué.

Au delà de la performance pure et de la mise en avant du processeur UltraSPARC T2, ce nouveau test permet surtout de valider le modèle d’un système de cache central. Dans ce cas il ne s’agit que d’un serveur connecté via une interface 10Gb, 64G de RAM et surtout du dernier processeur UltraSPARC T2. Ce dernier ayant la particularité d’embarquer 8 cores, chacun pouvant exécuter 8 threads. Et comme vous pouvez le constater sur ce tableau, les chiffres de requêtes par seconde sont impressionnants :
Lire la suite »


Elastic MapReduce : Un nouveau service dans les Clouds d’Amazon

April 28, 2009

amazon-web-services-mapreduceDécidément ils sont très actifs chez Amazon web services, en trois ans ils auront mis en place un système de service distribués trés complet (Cloud EC2, SimpleDB, Storage S3, Queue Service SQS). Le dernier en date concerne MapReduce, j’avais d’ailleurs déjà évoqué cette possibilité il y a un peu plus d’un an à la fin de cette note. Mais au fait ça sert à quoi MapReduce

Lire la suite »


Optimiser le fonctionnement d’un serveur sous Drupal

April 23, 2009

drupalDrupal est un outil de gestion de contenu qui connait un réel succès depuis 2007. Aujourd’hui ce CMS est utilisé sur des centaines de milliers de sites, et pas toujours comme CMS d’ailleurs. C’est la particularité de cet outil, sa conception modulaire permet en effet de le transformer à souhait.

Tout ça est très pratique, après la première phase d’apprentissage le développement est rapide et le code du cœur est fiable et robuste. Mais quid de la monté en charge… Lire la suite »


MemcacheDB : La base de données de Memcached

February 15, 2009

cactiDu nouveau chez Danga  /memcached, avec memcacheDB. Attention, contrairement à memcached, et comme son nom l’indique ce nouvel outil est une base de données. Elle utilise le même protocole que memcached mais stocke les enregistrements dans une base de type Berkeley DB.

Dans la même série sachez qu’il existe également MemcacheQ, un système de message également basé et compatible avec le protocole memcached. Et surtout je vous invite à lire l’excellent document de Steve Chu, qui présente en détail l’architecture de ce nouvel outil :
Lire la suite »


Stockage distribué : Project Voldemort

February 1, 2009

voldemortLa gestion d’un nombre de requête important nécessite toujours la mise en place de système de cache. En général il s’agit de système permettant de stocker une valeur pour un ID donné.

Dans cette gamme de logiciel je vous ai déjà présenté memcached, ou les solutions de montée en charge de Danga, aujourd’hui je vous propose de regarder le projet Voldemort.

Ce nouveau système est en fait une implémentation libre du système Dynamo d’Amazon (Dynamo est également expliqué ici): Lire la suite »


Communiquer via une file d’attente de message [3/3]

January 31, 2009

amazon-queue2Après avoir analysé les avantages de la communication par message pour l’envoi d’email massif et pour décharger le nombre de thread sur un serveur web, nous allons aujourd’hui nous intéresser à la répartition de charge.

Dans les cas ou plusieurs clients peuvent demander un traitement particulier la communication par message est souvent intéressante. En effet elle permet de découpler les demandes des clients et les traitements par les serveurs. Les services web peuvent être répartis facilement grâce à un load balancer HTTP, mais dans certains cas les traitements à effectuer sont plus importants que le simple calcul d’une page. Il est alors beaucoup plus intéressant de passer par une liste de tâches partagées par les clients et les serveurs. Lire la suite »


Communiquer via une file d’attente de message [2/3]

January 19, 2009

post_office1Après vous avoir présenté brièvement les avantages de la communication par message dans ce premier post. Je vous propose de continuer cette série mais en s’intéressant cette fois aux tâches longues, complexes et souvent gourmandes en ressource.

Dans ce deuxième exemple nous sommes toujours sur une application web, mais dans cette partie l’utilisateur souhaite obtenir un objet dynamique relativement long à générer. Cela peut-être un rapport à consolider, une analyse sur une grosse base de données, ou une sauvegarde à lancer et à télécharger.

En général dans les développements fait un peu trop rapidement, c’est la première demande qui va se charger de lancer le traitement, de suivre l’avancement, d’en informer le client jusqu’à la fin pour lui proposer finalement de télécharger son résultat. Le problème avec cette méthode c’est que pendant tout ce temps nous allons garder une connexion ouverte, et donc monopoliser un thread coté serveur. Cette monopolisation va naturellement réduire la disponibilité du serveur car le nombre de thread parallèles est physiquement limitée par la mémoire de la machine.

La technique consiste donc à séparer cette demande de traitement en deux partie associées par un identifiant stockée en base de données : Lire la suite »


Communiquer via une file d’attente de message [1/3]

January 16, 2009

boite-au-lettre-2Aujourd’hui la construction d’un service ou site web se fait généralement via l’appel de services et requêtes HTTP. Du coup la modélisation d’une architecture est souvent basée autour de ce protocole et toute l’architecture est basée sur ce principe.

Pourtant il existe d’autres techniques qui permettent à des systèmes de communiquer entre eux. Je vous propose donc via ces quelques pages de vous faire (re)-découvrir le principe de la communication par message asynchrone. La grande différence entre les messages asynchrones et les requêtes synchrones tient au fait que l’émetteur d’une requête va attendre sa réponse et il ne va pas interrompre la communication tant que le traitement ne sera pas terminé (get http par exemple).

Alors qu’avec un message, le récepteur va confirmer le bon enregistrement de la demande et la communication peut-être interrompue même si le traitement demandé dans le message n’est pas terminé.

Prenons l’exemple de l’inscription d’un utilisateur sur un site web, à la fin de l’inscription nous souhaitons lui envoyer un e-mail de confirmation/vérification :

Lire la suite »


CloudFront : Amazon lance son service de CDN (Content Delivery Network)

November 18, 2008

On me pose souvent la question du coût des solutions de CDN Akamai pour gérer la disponibilité d’un site. Et en général le problème majeur avec cet acteur vient des frais de fonctionnement et de mise en service. En effet au delà de l’engagement contractuel sur la durée la mise en place d’une solution Akamai est relativement coûteuse pour des “petits” acteurs.

Cette annonce d’Amazon est donc une très bonne nouvelle pour le segment des sites de taille moyenne, trop petits pour négocier avec Akamai et gérant déjà un trafic suffisamment important pour être obligé de mettre en place des solutions de cache distribués, des CDN.

Concernant l’offre d’Amazon, elle ne m’étonne pas beaucoup et elle vient compléter les autres produits de la gamme. Pour les tarifs vous trouverez tout sur le site, mais voici un premier aperçu : Lire la suite »


Planning des évolutions de votre architecture web

September 25, 2008

Lors de la dernière conférence LinuxWorld, John Engales le CTO de Rackspace a présenté les différentes étapes de la vie d’un site web. Et même si chaque site possède sa problématique il est toujours intéressant de voir qu’il existe un schéma général.

En quelques lignes voici donc les différentes versions d’une infrastructure web typique, j’ai simplement changé deux points (en gras et/ou barré) qui sont plus proches de la réalité des cas que je rencontre de ce coté de l’atlantique :

  • Etape 1 : Architecture simple, pas de redondance, pas de complexité. Un firewall, un serveur Web et une base de données avec stockage local (load balancer web, rare à ce niveau).
  • Etape 2 : La même chose mais avec un load balancer sur deux serveurs web et une base de données un peu plus puissante
  • Etape 3 : Mise en place d’un reverse proxy, d’un cache statique et de load balancers sur les bases de données (avec synchro master/slave par exemple). Il faudra prévoir quelques recodage à cette étape.
  • Etape 4 : La complexité commence : Ajouter du memcached (ou autre), les réplications entre les bases de données deviennent trop gourmandes en ressources et il va falloir commencer le split horizontal (partitionnement des données, nécessitant un re-design des BDD). A ce niveau la mise en place de serveurs dédiés en fonction du contenu a du sens.

A partir d’ici les choses commencent vraiment à devenir sérieuses, bonne nouvelle pour le trafic du site ou du service mais il va désormais falloir assurer une disponibilité sans faille. Lire la suite »