Création de sites internet
Formations pour Webmaster
Notre agence web vous accompagne dans toutes les étapes pour réaliser vos projets internet.
Nos sites sont vraiment dynamiques!
(Pour preuve: vous pouvez modifier cette page simplement en déplaçant les éléments avec votre souris!)
Je note que Rue du Commerce va migrer des infrastructures Completel à celles de Iliad... C'est le retour des Dedibox ?
Pixmania utilise 600 serveurs dans 4 datacenters pour répondre à une fréquentation de 5 millions de visiteurs en journée normale. Mais la fréquentation peut se multiplier rapidement en période d'achats... Ca revient à gérer 10.000 visiteurs par serveur ?
PriceMinister a fait le choix de la mémoire vive: 128Go de RAM dédiée à la base de données!
Une page internet fait en moyenne dans les 500Ko en taille totale. Mais le plus gros volume se concentre dans les images. Le code HTML ne revient qu'à environ 10Ko, soit 2% du poids total!
Pour le serveur web, une page se compose de plusieurs dizaines de requêtes: le contenu HTML, puis ensuite le CSS, le javascript et enfin le multimedia (images, videos, animation flash, musiques, etc...). On compte environ 30 requêtes au total et seule la première fournit le résultat de la requête, ce qui donne que 3% des requêtes gérées par le serveur web sont liées à la base de données du CMS.
La première phase de gestion de la montée en charge consistera alors à distribuer les contenus annexes (non HTML) sur différents serveurs. Cela se réalise facilement de manière applicative et apporte un gain de plus de 90% sur la charge du serveur web!
Pour le contenu HTML qui provient du CMS et donc des bases de données, la page d'accueil ne change pas si souvent et on peut limiter son changement avec un cache d'une minute. Sur 24H, il y a 1.440 minutes, ce qui revient à moins de 1.500 requêtes pour construire la page d'accueil et à un intervalle de 1 minute entre chaque requête. Il faut noter que les navigateurs web des visiteurs ont un cache qui est beaucoup plus long qu'une minute. On ne perturbe donc pas l'expérience utilisateur avec cette régulation.
Pour les sites qui proposent un très large catalogue, les visiteurs auront des centres d'intérêts très variés. Ce qui va provoquer un nombre de requêtes très différentes. Il faut alors mettre en place un cache pour les requêtes les plus fréquentes, comme pour la page d'accueil. Mais pour les requêtes les moins fréquentes, il n'y a pas d'autres choix que d'interroger la base de données... Pour améliorer l'expérience utilisateur, on peut décomposer la réponse en affichant une page d'attente qui reprend la requête demandée et puis en lançant une requête AJAX pour obtenir la réponse personnalisée. Cela permet de gérer des temps d'attente de quelques secondes à une minute (ou même plus...) En effet, les mécanismes AJAX permettent d'interroger le serveur régulièrement pour obtenir une réponse. Il est donc possible de gérer une file d'attente des requêtes du côté du serveur et ainsi de répartir la charge des requêtes sur le serveur.
Ces solutions simples, peu onéreuses et évolutives permettent d'accompagner les montées en charge d'un site de manière sécurisée.
Les dernières versions d'Ubuntu (10.04 et 10.10) sont maintenant installables sur les serveurs virtuels Gandi.
Après quelques semaines de turbulence, le serveur Gandi AI est redevenu stable. Il faut que je prenne le temps de tester cette nouvelle installation du serveur. Si les tests de robustesse sont concluants, je passerai en mode root sur les serveurs Gandi!
Cela me permettra à terme de doubler les serveurs de mails pour une meilleure sécurité et peut-être à terme de doubler les serveurs DNS ?
Tout un programme pour 2011!
La nouvelle API XMLRPC est en phase beta mais permet de redémarrer ou arrêter un serveur à distance. A long terme, il sera possible de créer des nouveaux serveurs dynamiquement à partir de disques modèles.
Espérons simplement que l'infrastructure réseau qui est en train de s'étendre aux USA sera stable et vraiment robuste. Pour le moment, le Cloud Gandi est moins robuste qu'un serveur dédié OVH...
Ces dernières semaines, Gandi n'arrête pas de subir des incidents.
Le système de monitoring que j'avais mis en place pour le serveur a mis en lumière encore plus de problèmes... Le serveur a des coupures réseau de manière chronique, ce qui rend le serveur web inaccessible sans que le serveur linux ne soit en cause. Mais comme le serveur est en infogérance Gandi AI, seul le support a vraiment les moyens de savoir là où se trouve le problème. Dans le doute, le service de monitoring effectue la seule chose qu'un utilisateur fait dans ces cas là: il redémarre le serveur! Mais le redémarrage des serveurs Gandi AI est aussi problématique, car il est très lent et peut prendre plus de 10 minutes avant que le serveur web soit de nouveau opérationnel!
Comme limite acceptable, le seuil d'alerte du monitoring était à 5 minutes d'indisponibilité. Ce qui entraîne des redémarrages en cascade... Il va donc falloir que le seuil soit rallongé... est-ce que 30 minutes permettront de stabiliser le monitoring ? En tout cas, c'est inacceptable du point de vue du fonctionnement du serveur web.
Assez étrangement, cette série de problème se déclenche alors que Gandi fait évoluer son infrastructure réseau et ouvre des datacenters au US. Quelle est la part de problèmes internes ou des attaques extérieures ? En tout cas, le fameux cloud computing avec ses promesses de robustesse et de redondance n'est pas là! En comparaison avec un serveur dédié OVH, les serveurs dédiés sont moins protégés mais une fois configurés, les serveurs OVH fonctionnent de manière très stable. Et avec Ubuntu 10.04 LTS, un redémarrage met moins d'une minute!
Dès que la distribution Ubuntu (64bits) 10.04 LTS sera disponible sur Gandi, je ferai un essai en mode root et si c'est concluant, je ferai une migration du serveur AI actuel vers un serveur dédié.
Ce matin, le serveur virtuel du site a redémarré, mais le redémarrage n'a pas réussi. Le serveur est donc resté indisponible toute la journée!
En fin d'après-midi, à mon retour, j'ai constaté le problème et j'ai pu redémarrer le serveur virtuel avec l'interface Gandi.
Pourquoi est-ce que les précédentes tentatives de redémarrage ont échoué ? Comme le serveur virtuel est en infogérance avec Gandi AI, je n'aurai peut-être jamais d'explication...
Dans mon planning, j'avais prévu de créer un nouveau serveur virtuel en mode 'root'. Je vais avancer cette tâche pour me débarrasser de ce serveur Gandi AI qui est trop instable.
A suivre...
Le service WatchMouse de monitoring de disponibilité des sites internet a suivi pendant un mois une dizaine de sites commerçants.
Et Groupon a obtenu une mauvaise note!
Pour le site Groupon: plus de 26 heures d'indisponibilité sur la période du 22 Novembre au 22 Décembre. Ce qui donne moins de 96% de disponibilité pour le site internet, alors que le standard dans le domaine est de 99.9%...
C'est sur que ne pas pouvoir accéder à un site est une expérience frustrante pour les consommateurs. Mais est-ce que cela ne fait pas aussi partie de la stratégie marketing ? Comme un prix élevé pour afficher que ce n'est pas pour tout le monde ?
Naturellement, il faut que l'indisponibilité des sites soit uniquement dû aux pics de fréquentation, ce qui renvoie une partie de la responsabilité aux visiteurs. Le monde réel est plein d'exemples de files d'attente interminables, alors le monde virtuel peut aussi s'en permettre?
Depuis quelques semaines, les serveurs virtuels Gandi sont particulièrement instables... Le serveur web de ce site devient régulièrement indisponible pendant plusieurs minutes. Jusqu'à maintenant, mon système d'auto-reboot en cas d'indisponibilité du serveur fonctionnait bien. Mais maintenant, le reboot peut planter (ou être très long... si vous voyez une différence ?). La méthode conseillée par Gandi serait un "stop" and "start", mais le problème, c'est qu'on ne peut pas avec l'API actuelle poser 2 opérations... Et quand le serveur est stoppé, il ne peut pas se démarrer lui même :-( Il faudra donc ajouter un monitoring actif depuis un autre serveur...
A suivre...
Micro Web Agency
1 rue de la Haie Cochin
78830 Bonnelles
France
tel: +336 24 22 37 36 
fax: +339 72 12 45 48
SIRET: 49464429700025 TVA: FR34 494644297