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 »


Système d’email haute volumétrie

April 1, 2009

lavabitComment gérer des centaines de milliers de mails par jour, soit environ une dizaine d’email par seconde de manière continue ou encore des dizaines de Tera de données par jour… C’est ce que vous pourrez apprendre en consultant cette page.

Il s’agit d’un document extrêmement complet sur la manière dont Lavabit traite les 260 000 comptes emails qu’ils ont en gestion. L’architecture est basée sur une petite trentaine de serveurs. Au programme : un cluster Cyrus, du SMTP, du POP, du PostFix et au niveau de la consultation, la charge est répartie par un load balancer Alteon AD4.

Lire la suite »


Comment les blogs Skyrock livrent 5 milliards de pages par mois

March 9, 2009

skyrockC’est ce que vous pourrez découvrir dans le dernier entretien de Jérôme Aguesse (Directeur de production chez Skyrock) dans 01informatique. Vous pourrez notamment y apprendre que cette une plate forme LAMP (Linux, Apache, MySQL et PHP) répartis par des load balancer (ZXTM de Zeus, ServerIron de Foundry Networks) et comment les bases de données MySQL sont réparties en étoile grâce à une synchronisation Master/Slave.
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 »


L’architecture et les bases de données du site Digg

February 4, 2009

diggLe site Digg est connu pour être un énorme fournisseur de visiteurs (surtout quand vous êtes sur la première page) mais comment gèrent-ils leur propre trafic. Pour vous donner un ordre d’idée, il y a six mois Digg drainait plus de 20 millions d’utilisateurs et 220 millions de pages vues par mois. Ce trafic représente une moyenne constante de plus de 100 requêtes par seconde… Pour gérer tout ça nous retrouvons un petit ensemble de mots magiques : Debian, MySQL, Memcached, MogileFS, Python, PHP, Apache..
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 »


Les points à vérifier pour fiabiliser votre architecture

October 28, 2008

Il est parfois utile de faire une pause dans l’exploitation quotidienne pour vérifier que les optimisations et contrôles basiques sont bien en place. C’est ce que propose cette petite liste. Elle vous permettra de vérifier que rien ne vous échappe dans votre architecture. Elle provient du blog www.productionscale.com, et plus précisément de cette note à propos de la planification et du suivi d’un système.

Voici un résumé de cette note qui regroupe un ensemble de bonne pratique  :

  • Gérer le déploiement : Votre système de publication doit intégrer un workflow précis, gérer les versions et le retour en arrière en cas de problème. De plus le déploiement doit être complètement automatique et indépendant du parc matériel.
  • Découpage fonctionnel : Décomposer votre application en silos fonctionnels afin de disposer de composants optimisés par tache.
  • Partitionner vos données : Séparer les requêtes de lecture et d’écriture, et dès le début penser à un moyen de diviser/partitionner vos bases.
  • Séparer les contenus dynamiques et statiques : Vous pourrez plus facilement les gérer grâce à des reverse proxy ou via un CDN. Lire la suite »

La gestion des risques chez Merrill Lynch avec les iDataPlex d’IBM

October 16, 2008

Pas de commentaires sur les fluctuations boursières ici mais une information sur le déploiement de la dernière série d’IBM : les iDataPlex. Cette gamme est dédiée aux centres de calcul et ils sont optimisés au niveau électrique et énergétique.

C’est justement ce qui est recherché par Merrill Lynch dans cette opération, obtenir de grosses capacités de calcul pour pouvoir modéliser et analyser les risques de leurs produits financiers. L’architecture innovante de cette gamme permet en effet de concentrer dans un petit volume (à partir de deux baies) une centaine de serveurs avec une consommation électrique et un dégagement calorifique très faible. Attention sur ce dernier point, la porte avec fluide de refroidissement est une option, et votre datacenter doit être compatible (arrivée d’eau).
Lire la suite »