Aujourd’hui, la team bichon a décidé d’aborder le sujet des performances logicielles. Plus précisément de performances d’applications web.

Le contexte

Posons les bases : qu’est ce que j’entends par problèmes de performances ? Je ne vais pas parler d’une application java qui n’arrive pas à encaisser 50 000 connexions à la seconde. Je parle plutôt d’une application qui va être lente à afficher des pages, lentes dans ses traitements, ou qui ne pourra pas répondre à un nombre satisfaisant de requêtes simultanées. On peut estimer qu’une application lente, c’est une appli qui va mettre plus de deux secondes à afficher une page (un peu comme ce site par exemple, merci wordpress 😉 ).

Dans ce qui suit, je vais me baser sur des expériences réelles et vous donner quelques pistes d’analyses.

En parlant d’expérience réelle, je ne compte plus le nombre de projets qui ont des soucis de performances… d’ailleurs, après réflexion, je crois que je n’ai jamais travaillé sur un projet qui n’avait pas de problèmes de performance !

En discutant avec certains prestataires du temps où je travaillais en société de service, il y avait souvent un leitmotiv qui revenait :

« ça ne sert à rien d’optimiser le code, il faut d’abord livrer quelque chose qui marche dans les délais ». Et ces mêmes programmeurs de citer la fameuse phrase de Donald Knuth :

« L’optimisation prématurée est la racine de tous les maux (ou, du moins, la plupart d’entre eux) en programmation. »

C’est là que je m’insurge ! Et vu que j’ai mon petit coin de web pour m’exprimer j’en profite 😉

En effet, cette citation est mal interprétée par nos amis devs. Je ne me permettrai pas de remettre en cause l’auteur de cette citation (une pointure dans son domaine), mais dans son propos, l’auteur parle de « micro optimisations ». C’est à dire d’optimisation de langage, ou de bout d’algo qui font gagner quelques millisecondes.

Et là, je suis tout à fait d’accord avec M.Knuth. Dans un premier temps, la micro optimisation fait perdre du temps dans sa mise en œuvre pour peu de gain en terme logiciel. En revanche, une application performante doit être pensée dès le début pour que ce soit le cas.

Qui est mieux placé que le développeur pour penser à la technique de son application ? Bon ok, il y a les architectes 🙂 Mais ce n’est pas dans toutes les sociétés qu’il y en a. Donc c’est au dev qu’incombe la charge de penser son application, sa structure de code pour qu’il soit performant. D’ailleurs, c’est à mon avis l’un des points les plus intéressants de la programmation.

Lorsque les devs faillissent à leur tâche, que dis-je, à leur devoir, c’est souvent très tard que l’on s’aperçoit des problèmes de performance. Généralement, si vous avez la chance de travailler avec une équipe de tests, ils vont passer votre application à des tests de monté en charge sous Jmeter ou gatling. Et là, si vous ne l’avez pas fait vous-même, ce sera le drame… votre application ne supporte pas la connexion simultanée de 5 utilisateurs (ne riez pas, c’est du vécu). Elle mets 10 secondes à retourner le résultat d’une requête etc. Bref, retour illico presto du logiciel à l’envoyeur, et bon courage pour éviter de tout casser pour remettre l’application sur pied.

Bref, vous l’aurez compris, la performance logicielle, c’est à mon sens, plusieurs enjeux cruciaux :

  • Réduction du coût logiciel en livrant une copie acceptable d’entrée de jeu.
  • Le cœur de la satisfaction utilisateur. Des études ont été faites à ce sujet (google, amazon etc)
  • Pérennité d’un projet qui vieillira correctement.

Vous voilà convaincu ? nous allons pouvoir passer aux choses sérieuses.

Dans cette mini série sur l’optimisation, nous allons imaginer que nous avons des problèmes de perfs sur une application java coté back (micro service ou pas, peu importe), une base de données SQL (nous verrons plus tard avec du NoSQL), et un front en angular ou reactJS.

Le premier article traite de l’optimisation SQL

Le second de l’optimisation java

et le troisième traitera du front-end.

Partager sur les réseaux