wOueb by Romain DECKER / Another IT Guy Blog

Vous avez créé une application, ou un site web susceptible d’avoir un grand nombre de visiteurs ? Pour éviter l’effet Slashdot (indisponibilité de votre site suite à une rapide augmentation du nombre de visites), il est conseillé de faire des tests de montée en charge.

Plutôt orienté « sites web », Load Impact (comme son nom l’indique) permet de simuler un nombre croissant de visiteurs sur votre site et de vérifier l’impact sur les temps de chargement, l’accès aux pages, etc.

Le résultat obtenu est plutôt visuel : outre les chiffres, vous trouverez dans votre rapport des graphiques d’évolution.

Test de montée en charge avec Load Impact

On peut voir que ce test :

• a duré 10 minutes,
• que le volume de données total transféré est presque de 450 Mo pour 22500 requêtes,
• a consisté à un incrément de 10 utilisateurs toutes les 2 minutes pour atteindre 50 utilisateurs simultanés.

Une version gratuite mais limitée est disponible : elle permet de faire 4 tests par jour, avec 50 utilisateurs simultanés au maximum. Pour les autres versions, il faudra sortir la carte bancaire, mais les prix sont totalement abordables !

Load Impact : prix

J’ai eu l’occasion de tester des solutions professionnelles pendant quelques années et je trouve que :

• la configuration des scénarios est un peu faiblarde,
• la montée en charge devrait être mieux gérée : possibilité de faire des paliers d’utilisateurs en dent de scie, etc.

Cependant, cette solution de test de montée en charge proposée par Load Impact a l’avantage d’être hébergée : il n’est pas nécessaire d’installer un client sur un (ou plusieurs) poste(s).

Enfin, quid de la simulation d’utilisateurs visualisant des vidéos en streaming (type Youtube) ? J’ai trouvé ceci dans la FAQ :

Load Impact will load the video file, if it is accessible via standard HTTP/HTTPS, but each client will stream (load) the file as fast as possible, which means you’re likely to get much « heavier » clients than you would in a real scenario.

Pour ceux qui veulent se donner une idée, le résultat du test gratuit sur mon blog est disponible en ligne, et pour ceux qui veulent l’essayer : Load Impact.

Vous obtenez de bons résultats ?

Merci à Gonzague pour la découverte

Tout comme 2009, 2010 a été une année bien remplie, même pour mon blog : un nouveau thème a fait son apparition, ainsi qu’un nouveau serveur pour héberger le tout !

J’ai repris une écriture plus régulière au courant de l’été, et j’ai encore des brouillons / idées d’articles plein les cartons, j’espère que je trouverai le temps de tous les publier ! Le blog manque encore un peu de commentaires malgré les visites, je compte sur vous pour y remédier en 2011 !

Bonne année 2011 !

Meilleurs vœux à tout mes lecteurs, et bonne et heureuse année 11111011011* !

* : 2011 en binaire

Facebook est une vraie machine de guerre : on a pu voir récemment que c’était le site le plus visité au monde, et tout ça seulement après quelques années. Contrairement à d’autres « supergrands » (Google, Microsoft, Apple, Youtube, etc.) un certain nombre d’informations filtrent lors de conférences, et dans des documents officiels.

Je rappelle que pour écrire ces 2 articles, j’ai simplement visionné des vidéos de conférences pour compiler les informations. Vu la masse de détails obtenus, j’ai publié deux articles :

• le précédent, présentant les chiffres clés sur l’infrastructure de Facebook,
• celui-ci : comment Facebook gère quotidiennement son (immense) infrastructure ?

En extrapolant plusieurs données (graphiques d’évolution, chiffres passés, etc.) on estime entre 60 000 et 100 000 le nombre de serveurs de Facebook .

Facebook : évolution du nombre de serveurs

Cependant, ce chiffre ne tient pas compte de deux nouveaux datacenters actuellement en cours construction (Oregon et Caroline du Nord).

Facebook a depuis longtemps atteint une masse critique qui nécessite de voir sa copie en terme d’administration quotidienne.

Un des ingénieurs de Facebook a bien illustré le problème lors d’une conférence :

With Facebook users spending a collective 8 billion minutes on the site each day, serving 1.2 million photos each second, and managing more than 25 terabytes of data per day in logging data, we’re forced to think about servers and datacenters differently.

Nb : les chiffres sont de 2009, les actuels sont présents dans mon article précédent.

(suite…)

Le moteur de base de données MySQL est très largement utilisé dans le monde. Même si l’installation et le paramétrage par défaut de MySQL suffit amplement pour un site web ou un blog, il est nécessaire de l’optimiser dans le cadre d’une utilisation plus « corporate« .

Deux leviers majeurs sont disponibles :

• l’optimisation du serveur de base de données (ou de la ferme de serveurs),
• l’optimisation du code.

La commande « show status » (en CLI, ou via phpMyAdmin) offre un certain nombre d’informations sur le statut d’un serveur MySQL.

MySQL : résultat de la commande show status dans phpMyAdmin

Cependant, les informations rendues ne sont pas toujours exploitables facilement (ni rapidement) pour les personnes qui ne sont pas DBA.

C’est là que mysqlreport intervient : c’est un simple exécutable qui va vous permettre de synthétiser le statut d’un serveur MySQL. Il suffit de télécharger ce fichier (pas d’installation nécessaire), et de le lancer en lui renseignant les paramètres de connexion au serveur MySQL, pour qu’il vous exporte un résultat assez sympa !

Jugez plutôt :

Pour ceux qui voudrait plus détails sur les valeurs obtenues et savoir comment les interpréter (et les comprendre), je vous invite à lire ceci : The guide to understand mysqlreport.

Que se passerait-il si Google mettait un lien vers votre site/blog en page d’accueil ?

Votre serveur subirait un afflux massif de visiteurs curieux : la conséquence directe serait une surcharge importante, qui rendrait très certainement votre site indisponible.

Ce phénomène est appelé effet Slashdot, ou slashdotting (moins courant). Ce terme provient de l’afflux considérable de trafic web lorsqu’un site est linké par Slashdot.org, sorte de digg-like pour geek.

Pour réussir son Slashdot Effect, 3 étapes sont nécessaires :

1. 1. un site (très) populaire met un lien vers un site plus petit,
2. 2. les zombies du web et autres affamés du clic internautes cliquent à tout va,
3. 3. le serveur hébergeant le site plus petit subit de fortes lenteurs, ou devient indisponible du fait de la masse de connexions.

Le graphique suivant représente l’évolution de la bande passante par rapport à une échelle de temps. On voit qu’à partir d’un instant T, la bande passante est plus que décuplée : ça représente l’effet Slashdot.

Les goulots d’étranglement peuvent être multiples : bande passante, requêtes vers la base de données, limites de processus Apache, système de cache absent, mauvais développement, etc.

Il est légitime de se poser quelques questions :

• comment prévenir et conserver un minimum de disponibilité si ça arrive ?
• que faire si cela arrive et que votre site est complètement indisponible ?
• jusqu’à quel point être vous prêt à accepter une dégradation de service ?

Se poser ces questions est un bon début, car vous êtes conscient que le problème existe.

Facebook est une vraie machine de guerre : on a pu voir récemment que c’était le site le plus visité au monde, et tout ça seulement après quelques années. Contrairement à d’autres « supergrands » (Google, Microsoft, Apple, Youtube, etc.) un certain nombre d’informations filtrent lors de conférences, et dans des documents officiels.

J’ai visionné plusieurs heures de vidéos de conférences (long mais super intéressant) et ait compilé les informations. Vu la masse de détails obtenus, j’ai décidé de publier deux articles :

• celui-ci, présentant les chiffres clés sur l’infrastructure de Facebook,
• un second (à venir) : comment Facebook gère quotidiennement son (immense) infrastructure ?

En extrapolant

• certains graphiques d’évolution,
• des chiffres passés,
• des indications fournies pendant des conférences,

on estime entre 60 000 et 100 000 le nombre de serveurs de Facebook . Cependant, ce chiffre ne tient pas compte de deux nouveaux datacenters actuellement en cours construction (Oregon et Caroline du Nord).

Facebook : évolution du nombre de serveurs

Mais qu’est-ce qui peut bien tourner sur cette infrastructure ?

Données générales :

• 500 millions d’utilisateurs actifs (un utilisateur actif est un utilisateur qui se connecte au moins une fois par mois),
• 50% des utilisateurs se connectent au moins une fois par jour, soit 250 millions de personnes tout de même,
• 690 milliards de pages vues par mois,
• 6 milliards de contenus partagés par semaine (statuts, photos, liens, vidéos),
• 3 milliards de photos uploadées par mois, pour plus d’un pétaoctet de stockage uniquement destiné aux photos (chaque photo existe en 4 tailles),
• un dernier chiffre, le plus parlant peut-être : 16 milliards de minutes sont passées par jour sur Facebook. Ça représente 11 millions de jours ou encore plus de 30 000 années qui sont passées par jour sur le réseau social, c’est juste énorme !

Données techniques :

• plus de 300 To (téraoctets) de données en cache en RAM avec Memcached,
• 25 To (téraoctets) de log par jour,
• un ingénieur Facebook pour 1,1 millions d’utilisateurs. A titre de comparaison, Google emploi un ingénieur pour 190 000 utilisateurs,
• un opérateur Facebook pour 2,3 millions d’utilisateurs.

Quelques chiffres intéressants sur MySQL :

• 13 millions de requêtes par seconde en pic,
• 38 Go/s de trafic MySQL en pic,
• temps de réponse moyen en lecture : 4 ms,
• temps de réponse moyen en écriture : 5 ms,
• 450 millions de lignes lues par seconde en pic,
• 3,5 millions de lignes modifiées par seconde en pic,
• 5,2 millions d’I/O (disques) InnoDB par seconde.

Qui a d’autres chiffres intéressants et récents à partager ?

Dans le prochain article sur le sujet, je traiterai de la gestion quotidienne d’une infrastructure de cette taille.

Sources :

• A Day in the Life of Facebook Operations,
• Facebook on Bandwidth,
• MySQL Tech Talk.