Au-delà du profilage

1. Introduction

Avant de réarchitecturer la totalité de la solution, il reste de nombreux points que nous pouvons améliorer sur PROFI sans fondamentalement changer son comportement.

Dans le chapitre précédent, nous nous sommes attachés à montrer les erreurs traditionnelles posant des problèmes de performance, et ce exclusivement sur la partie API. Il s’agissait de démontrer qu’un manque de performance ne nécessite pas toujours (loin s’en faut) une expertise pour trouver la parade, mais provient souvent d’une dizaine de cas de programmation relativement bien identifiés.

Il existe de nombreux autres cas qui, sans relever du tuning, restent des erreurs de programmation connues pour entraver la performance, mais suffisamment peu fréquentes pour ne pas justifier un chapitre spécifique. Il ne s’agit d’ailleurs nullement ici de prétendre à une quelconque exhaustivité, mais de présenter quelques cas concrets, de façon à améliorer l’appréhension du problème par le lecteur.

Le but de ce chapitre est également de proposer quelques méthodes simples pour améliorer la performance d’une application, sans nécessairement que ceci corresponde à la correction d’une erreur de code, mais sans que nous puissions non plus parler de tuning vu la simplicité des solutions proposées.

L’auteur ne proposera plus nécessairement des méthodes détaillées, mais parfois un simple retour d’utilisation sur des technologies particulières, associé à des conseils d’utilisation (voire d’abandon).

2. Amélioration du ressenti

Performance réelle et performance perçue

Des développeurs peuvent avoir une évaluation positive de la performance de leur code, benchmarks à l’appui, alors que le client utilisateur considère l’application comme lente. Derrière cette réalité, il se peut tout d’abord que le développeur travaille sur une machine puissante, et de ce fait ne considère que sa propre perception de la performance, basée sur son matériel.

Il se peut également que le mode de chronométrage d’une fonctionnalité...

1. Caveat

Que pouvons-nous faire lorsque nous avons passé en revue tous les points "classiques" expliqués dans ce livre et que nous avons toujours des problèmes de performance sur notre application cible ? Il est alors temps de passer à la seconde phase, dite de tuning, où nous allons ajuster plus finement tous les paramètres à notre disposition, identifier les goulets d’étranglement du système, et gagner les quelques derniers pourcents de temps au prix d’un énorme effort. C’est de cette phase que vient la réputation de complexité de l’optimisation des performances, car la première phase dont nous avons parlé au long de ce livre est souvent sous-estimée. Dans une énorme majorité des cas, il ne sera tout simplement pas nécessaire de passer à cette étape de tuning car la simple correction des portions de code incorrectes aura amélioré suffisamment les performances.

Cela a été répété abondamment tout au long du livre : il n’est pas question pour l’auteur de s’engager dans du tuning fin et des recommandations de performance qui n’auraient de sens que dans un contexte particulier. Tout au long des chapitres précédents, nous nous sommes penchés sur des erreurs "traditionnelles", courantes dans les applications et qui diminuent fortement la performance.

En introduction, nous avions présenté les trois phases de l’amélioration de performances d’une application.

Le profilage ayant fait l’objet de la plupart des chapitres précédents, nous allons brièvement parler de tuning. Il ne s’agit pas ici de réaliser une partie tuning alors que tout le reste du livre explique qu’il y a, dans 99 % des cas, des moyens beaucoup plus simples et sûrs d’améliorer la performance d’une application. Tout au plus allons-nous proposer des pistes et renvoyer le lecteur à une analyse plus approfondie de ces points, s’il a un jour besoin de les mettre en œuvre. La littérature est malheureusement abondante sur le tuning de performance. L’adverbe "malheureusement" se justifie par ces deux points :

1. Problématique

La section précédente a parlé de tuning, en expliquant que cette phase suivait le profilage dans le cas où celui-ci n’aurait pas permis d’atteindre les objectifs de performance fixés. D’expérience, l’auteur peut assurer que sur des applications non critiques, c’est rarement le cas.

Mais si nous devons passer par cette seconde phase, et que nous sommes absolument certains que le profilage ne nous remonte plus aucun cas standard, qu’il s’agit simplement de la complexité inhérente de l’application qui la rend lente, comment ne pas perdre notre temps avec du tuning fin, qui va fonctionner sur un système mais pas sur un autre à peine différent, et donc être peu exploitable et peu rentable ? Surtout, une fois cette phase de tuning réalisée, que faire si les performances exigées ne sont toujours pas atteintes ?

Il est temps alors de passer à la phase suivante, qui consiste à boucler sur la phase initiale d’architecture, en revenant sur les fondamentaux de l’application et en la repensant en profondeur. Notre base de données limite notre montée en charge ? Sous certaines conditions, des bases de données peuvent être placées en mémoire vive, avec un gain de performance excellent. Une autre alternative serait de placer un cache de type Redis entre la base de données et l’application, de telle sorte que les données fréquemment consultées soient directement disponibles. Cependant, comme lors de chaque usage d’une technologie de cache, il faut prêter une attention particulière à l’invalidation des données, de telle sorte que la consultation restitue systématiquement des valeurs pertinentes d’un point de vue business. Des architectures simples et innovantes peuvent même nous permettre de nous passer purement et simplement d’une base de données et de conserver pourtant la plupart des fonctionnalités qui lui sont associées.

2. Scalabilité