September 02, 2014

L'impact de la migration - performances doublées

Ce billet, au titre racolleur, s’inscrit dans le cadre d’une série d’article visant à expliquer comment j’ai réussi à diviser par 2 le temps de réponse de notre application Symfony2 sans toucher au côté applicatif.

Dans la série:


L’infrastructure

Voilà au final à quoi ressemble une partie de la nouvelle infrastructure (Varnish est OFF pour l’instant) :

Infrastructure

Les performances en cas d’usage réel, ça donne quoi ?

Je monitore l’application principalement avec NewRelic et Graphite. Voilà les metrics qu’ils ont pu relever:

Migration infrastructure performance applicative Symfony2 NewRelic

Migration infrastructure performance applicative Symfony2 Grafana

Temps de réponse moyen en usage réel:

Avant Après
1sec ~ 1.3sec 300ms ~ 400ms


Soit un temps de réponse divisé par deux, pas mal non ?

Conclusion

Voilà, mon retour d’experience est fini. L’application n’est restée inaccessible que 26 minutes, le temps de migrer la base de données.

Je suis conscient qu’il aurait été plus interessant de migrer brique par brique, pour terminer sur la migration hardware, afin de savoir quel composant apportait quel gain, mais j’avais une deadline serée pour migrer toute l’infra.

Je ne vous ai présenté que l’application Symfony2, mais au total, 8 serveurs ont du être installés et les projets migrés. Et je tiens d’ailleurs à remercier #Ansible sans qui j’aurais passer 2 fois plus de temps sur la migration (tiens, faudra que je fasse un REX sur Ansible…)

Au final, ce gain de 50% à été réalisé grace :

  • Au changement de réseau et de hardware (merci les SSD)
  • Au basculement de Apache / MySQL vers Nginx / MariaDB

La partie load balancing n’intervient pas dans ce gain, puisque lors de mes essais avec un seul backend, cela n’a pas impacté les temps de réponses. Elle intervient uniquement pour la scalabilité.