Les lancements sont nombreux et les effet d’annonce fatals ! Geoportail n’a pas vraiment pu etre accessible avant 1 semaine ou 2. Le site de la SNCF n’a dernierement pas survécu à la vente de billet TGV à 5? avec le prime le superbe resultat de 0 ventes en ligne ! mais oui ! La faute à qui ? trop de monde en même temps il parrait !
Je ne remets pas en cause ce fait car il est vrai que tout lancement conduit à un pic dramatique pour l’architecture… Mais si le fait est avéré, il est prévisible ! Qu’ont donc fait les chefs de ces projets pour palier à celà ?!? Pas grand chose semble-t-il, en tout cas je leur souhaite car les sommes investies en se sens l’ont été à pure perte vu le résultat !
La question que je me pose est la suivante : vaut-il mieux chercher à servir tout le monde avec une forte probabilité de ne servir personne ou servir une partie seulement des Internautes ? Il semble que ces CP aient choisi la première solution et cet article à pour but, vous l’aurez compris, de décrire comment employer la seconde.
J’ai en effet lu qu’avant l’opération TGV à 5 euros, la SNCF avait anticipé le pic en multipliant par 3 la capacité serveurs… Pour le résultat commercial donnée ci-dessus … c’est du gaspi ; je leur souhaite que celà s’inscrive dans un cadre d’extension global des capacités de leur infrastructure…. bref, la solution n’est pas de ce coté.
Ma vision de ce problème serait une approche différente ; les serveurs étant saturés par :
- La saturation de la bande passante d’entrée, dûe aux très nombreuses requetes concurente; mais il ne semble pas que ce soit le facteur premier
- La saturation des serveurs d’application, qui semble être plus directement concernée
S’attaquer à la seconde cause n’est pas vraiment compliqué, sans même multiplier le nombre de serveurs : actuellement, les applications web sont le genre de systèmes extrèmement lourds en consommation mémoire, requete de bdd, cpu. Elles sont l’accumulation des dizaines de couches logicielles : OS, JVM, bibliothèques diverses, jdbc, ejb, frameworks, jps / servlet de présentation … bref, à chaque ouverture de nouvelles sessions, tout ce petit monde se met en branle, réserve beaucoup de mémoire et consomme une quantité astronomique de temps CPU pour n’afficher qu’un bandeau, un menu et deux trois news … L’arrivée de milliers de connexions simultanées sature alors les ressources au point que l’application ne soit tout simplement plus accessible pour personne. La machine arrive rapidement dans un etat de saturation où son temps de réponse n’est plus lineaire mais exponnentiel ; autant dire que le serveur est planté.
Une bonne solution, économique, pour se sortir de cette situation est de protéger ces serveurs de la saturation en limitant le nombre d’utilisateur concurent pouvant accéder à l’application. Celà revient à limiter le nombre de sessions simultanées. Pour empécher la saturation, cette limitation sera prise en compte par un serveur différent dont le rôle, sera, par l’utilisation d’une technologie la plus légère possible, de recevoir toutes les demandes de connexion et de ne transmettre que celles pouvant etre traitées à l’application. Les autres etant renvoyées proprement sur une page d’erreur ou d’information.
L’utilisation d’une technologie légère est la clef de cette solution. J’imagine que les modes “cluster” de serveurs apaches doit pouvoir être configurable en ce sens en limitant le nombre de sessions par serveur : jusqu’a une certaine limite, les sessions sont redirigées vers l’application, les suivante vers une simple page HTML d’erreur.
Bref.. ce n’est qu’une ébauche de solution est il y en a de multiples autres, le tout etant d’y réfléchir et de prendre le problème par le bon bout, ce qui ne me semble pas etre souvant le cas !
La solution optimale serait d’intégrer ce genre de fonctionnalités dans des éléments réseaux matériels dédiés, ce qui existe peut etre, ou en tout cas ce ne serait pas très compliquer à construire pour des spécialistes.
Au passage ces solutions sont aussi une bonne protection contre les attaques en provenance des vers de type flood… ce sont donc des solutions toujours utiles, y compris hors lancement et campagne de promotion : un investissement durable.
En conclusion, les situations que j’ai évoqué et qui font la risée des utilisateurs me semblent majoritairement évitables. Leurs impacts peuvent être tout du moins amoidris et il me semble que ces problématiques doivent donc etres prises en compte plus sérieusement.
