Java
Free mobile: les erreurs du site d’inscription

Le site de Free Mobile a connu beaucoup de problèmes le jour de l’ouverture de l’offre: impossibilité de s’inscrire, inscriptions non prises en compte, etc.

Ne tenant pas la charge, le site à été réécrit pendant la nuit, en effectuant au passage une transition de Java (Jsf) vers Php.

En partant de ce constat, le troll Java Vs PHP est facile, mais plusieurs erreurs de conception ont largement contribué à l’écroulement du site:

Avant l’ouverture:
Avant l’ouverture officielle des inscriptions, le site de Free Mobile affichait un message du type : “dans quelques instants vous pourrez consulter nos offres”

  • Première erreur: Rechargement automatique toutes les minutes.

    la page se rafraîchissait automatiquement toutes les minutes.
    En plus des rafraîchissements manuels effectués par les impatients, ce code à généré un surplus de connexions et surtout a agit comme une retenue d’eau : à l’ouverture du vrai site, l’ensemble des utilisateurs en attente y ont accédé dans la première minute.….

À l’ouverture
Le site utilisait un système de “slots” pour le processus d’inscription : seul un nombre limité d’utilisateurs pouvaient s’inscrire simultanément. Les autres devaient attendre.

  • Deuxième erreur: Rechargement automatique toutes les 5 secondes.

    Lorsqu’aucun slot était disponible, le site affichait une page d’attente qui se rechargeait automatiquement toutes les 5 secondes pendant plusieurs minutes.
    En réponse à une surcharge, le site a multiplié volontairement la charge au bas mot entre 12x et 60x.

  • Troisième erreur: Choix de JSF
    JSF est un framework par composants, orienté applications web (type intranet), qui a besoin de stocker en session, pour chaque utilisateur :
    • L’état de l’ensemble des composants de la page courante
    • Le même état pour les X dernières pages visitées pour permettre l’utilisation du bouton précédent

    … là où les frameworks orientés sites web publics ne stockent que l’identifiant de l’utilisateur, dans le cas où celui-ci est authentifié.

    Dans le cas de free mobile, toutes les inscriptions sont faites par des utilisateurs différents. Le volume de données à stocker est donc énorme et n’est pas adapté à la fonction du site.

    Il est possible dans JSF de reporter ces données coté utilisateur en les intégrant dans le code html, au prix d’une augmentation de la bande passante. Cette configuration n’était pas utilisée sur free mobile.

Après la refonte:
Le site fonctionne maintenant en PHP, mais on peut voir que les leçons ont été tirées des problèmes ci-dessus:

  • En cas de surcharge du site, la page d’erreur redirige immédiatement vers la page d’accueil. Il n’y a plus de rechargement automatique. La redirection est même suffisamment rapide pour empêcher les utilisateurs de recharger eux-même la page trop facilement. (Note: La page principale est statique.)
  • Le site est en php basique, sans utilisation de framework visible. On se doute qu’il n’y a quasiment pas de données en session, voir pas du tout

Conclusion

  • Les rechargement de page en javascript sont dangereux sur les sites à forte charge. Il faut porter une extrême attention à leur impact sur le dimensionnement. Il vaut mieux privilégier un rechargement manuel de la page par l’utilisateur
  • La session est un élément sensible des applications web. Pour un site a forte audience, il faut limiter drastiquement les données stockées, ce qui exclut naturellement un certain nombre de frameworks de type JSF.

    En cas de nécessité, il est possible de déporter les données sur des caches mémoire, tels que memcache, ehcache, cohérence.

  • Un rappel: l’architecture mise en place ne dépend pas du langage. Faire une application complexe (modèle composant, de multiples couches, plein de données en session) ou ultra-simple quelques lignes dans un fichier est un choix, qui est réalisable de façon sensiblement identique dans les différents langages.

J’en profite également pour placer le projet open source Stateless Filter qui permet de déporter de façon transparente les sessions d’applications Java coté client ou dans un cache mémoire.

Les retours sont bien sûr les bienvenus. Je mettrai à jour l’article pour quelques corrections si nécessaire…


  • Rafael Aniello

    Je partage le point de vue de Nicolas: quand les principes de base ne sont pas appliqués (erreurs banales, non application du stateless, architecures foreuses, etc…) le langage ne compte que peu.
    Par contre l’analyse est très intéressante car c’est le genre de problèmes qui sont très simples à anticiper mais tout le monde oublie!

  • Daniel Le Berre

    Effectivement, l’erreur est grossière, et aujourd’hui encore le site web de free mobile fonctionne en mode minimaliste : pas d’accès à la consommation, pas d’achat de portables, pas d’ajouts de nouvelles lignes pour un compte, etc.

    A l’heure des méthodologies de développement agile, on a du mal à comprendre qu’une version dégradée mais contenant les fonctionnalités essentielles ne puisse pas être disponible 18 jours après la mise en ligne prévue initialement…

  • Mathieu Ruellan

    Le statefull peut quand même être envisagé.

    Suffisait pas de mettre un load balander avec des jsession_id avec un nombre max pour chaque node, et ce qui déborde par vers une page 503 sur un apache hyper léger.
    Si on compte 16ko par session, avec 16go de ram (ce qui est la norme en ce moment) on peut surement mettre plus de session en ram que le CPU et la BDD ne peut exécuter de requêtes.

    C’est d’ailleurs au niveau de la BDD que ca devait pécher. J’ai tenté de m’inscrire le 10, je suis arrivé plusieurs fois presque au bout, et c’est sur le “valider” final, où on fait sûrement le store, que çà plantait au bout d’un timeout.

    C’est là que je vois bien l’interêt de l’usage de un storage de type mongodb ou cassandra.

  • Jean-Paul Figer

    Avec un load balancer, en stateful si un serveur plante on perd les sessions, en stateless on ne s’en aperçoit pas et c’est plus simple à coder.
    Quand on veut comparer des langages, il faut bien sûr le faire à iso fonctionnalités. 
    Je ne sais pas ce qui a justifié le passage de Java à PHP (on a rarement vu l’inverse !) mais c’est peut-être aussi le nombre de lignes à coder (1 à 5 dans les tests sérieux que j’ai conduit) plus que la performance des machines ?

  • http://blog.richeton.com/ Nicolas Richeton

    Approche

    Le 29 janv. 2012 à 18:38, “Disqus” a écrit :

  • Mathieu Ruellan

    Au  pire, on met les sessions en persistance dans un mongoDB/CouchDB ou autre NoSQL …

  • 50 cent

    Meme pas vrai !

  • http://blog.richeton.com/ Nicolas Richeton

    Il est peu probable que le problème vienne de la base données s’ils ont choisi de réécrire l’appli (alors qu’elle  était terminée, on a vu des écrans dans le cache de Google). 

    D’autant plus que vu la simplicité du processus d’inscription, la base n’a pas grand chose à faire.
    Insérer disons 2 millions de lignes dans une table en une journée, c’est facile si la table n’est pas surchargée d’index  et ne tourne pas sur un serveur sous dimensionné.

    Sinon, ils ont peut-être utilisé un pool de connexions sans le configurer correctement ?

  • http://blog.richeton.com/ Nicolas Richeton