Les programmeurs choisissent les API, les structures de données et les structures globales des programmes en fonction de leurs attentes en matière de performances des API. Si les attentes ou les performances sont sérieusement erronées, le programmeur ne peut pas récupérer en ajustant simplement les appels d'API, mais doit réécrire le programme (éventuellement des parties majeures). La structure défensive du programme interactif évoquée plus haut en est un autre exemple.
Bien entendu, il existe de nombreux programmes dont la structure et les performances sont rarement affectées par les performances de la bibliothèque (le calcul scientifique et les grandes simulations entrent souvent dans cette catégorie). Cependant, une grande partie de « l'informatique classique » d'aujourd'hui, en particulier les logiciels intégrés aux services Web, utilise largement des bibliothèques essentielles à la performance globale.
Même de petits changements dans les performances peuvent entraîner des changements majeurs dans la perception d'un programme par l'utilisateur, en particulier dans les programmes traitant d'une variété de médias. Des pertes occasionnelles d'images du flux vidéo peuvent être acceptables, mais les utilisateurs peuvent percevoir même de légères interruptions dans l'audio, de sorte que de petits changements dans les performances du support audio peuvent avoir un impact significatif sur l'acceptabilité du programme dans son ensemble. Cette préoccupation a suscité un grand intérêt pour la qualité de service, qui consiste à bien des égards à garantir des niveaux de performance élevés.
Bien que les violations des contrats de performance soient rares et rarement catastrophiques, prêter attention aux performances lors de l'utilisation de bibliothèques de logiciels peut aider à créer des logiciels plus robustes. Voici quelques principes empiriques :
1 Choisissez soigneusement l'API et la structure du programme
Si vous avez la chance d'écrire un programme à partir de zéro, réfléchissez aux implications des contrats de performance lorsque vous commencez à écrire votre programme. Si le programme démarre comme un prototype puis reste en service pendant un certain temps, il sera sans doute réécrit au moins une fois ; une réécriture est l'occasion de repenser les API et les choix architecturaux.
2 Fournir des conventions de performances cohérentes lorsque de nouvelles versions sont publiées
Une nouvelle API expérimentale attirera les utilisateurs qui commencent à dériver des modèles de performances d'API. Après cela, changer les conventions de performances ne manquera pas d'irriter les développeurs et éventuellement de les amener à réécrire leurs programmes. Une fois l’API arrivée à maturité, il est important que le contrat de performance reste le même. En fait, la plupart des API à usage général (telles que la libc) le sont devenues en partie parce que leurs contrats de performance sont restés stables au cours de l'évolution de l'API. Il en va de même pour le port API
On pourrait s’attendre à ce que les fournisseurs d’API testent périodiquement les nouvelles versions pour vérifier qu’elles n’introduisent pas de bizarreries en termes de performances. Malheureusement, de tels tests sont rarement effectués. Cependant, cela ne signifie pas que vous ne pouvez pas effectuer vos propres tests sur les parties dépendantes de l'API. À l’aide d’un profileur, vous pouvez généralement constater qu’un programme dépend d’un petit nombre d’API. L'écriture d'un outil de test de performances qui compare les performances enregistrées d'une nouvelle version d'une API à des versions antérieures peut avertir les programmeurs que les performances de leur propre code changeront à mesure que de nouvelles versions de l'API seront publiées.
De nombreux programmeurs souhaitent que les ordinateurs et leurs logiciels deviennent constamment plus rapides au fil du temps. C'est en fait très difficile à garantir pour le fournisseur, mais il convaincra le client qu'il en est ainsi. De nombreux programmeurs espèrent que les nouvelles versions des bibliothèques graphiques, des pilotes et du matériel amélioreront les performances de toutes les applications graphiques et sont enthousiasmés par les améliorations apportées à plusieurs fonctions, qui réduisent souvent les performances des anciennes fonctions, même si ce n'est que légèrement.
On peut également espérer que la spécification de l'API rende explicite le contrat de performance, afin que les personnes qui utilisent, modifient ou portent le code puissent respecter le contrat. Notez que l'utilisation par une fonction de l'allocation dynamique de mémoire, qu'elle soit implicite ou automatique, doit faire partie de la documentation de l'API.
3 La programmation défensive peut aider
Les programmeurs peuvent utiliser des approches spéciales lorsqu'ils appellent des API dont les performances sont inconnues ou très variables, en particulier lorsque les performances en cas d'échec sont un problème. Nous pouvons déplacer l'initialisation en dehors des zones critiques en termes de performances et essayer de précharger toutes les données mises en cache que l'API pourrait utiliser (telles que les polices). Les API qui présentent d'importantes différences de performances ou qui possèdent de grandes quantités de données mises en cache en interne peuvent transmettre des indications de l'application à l'API en fournissant des fonctions d'assistance sur la façon d'attribuer ou d'initialiser ces structures. Un programme qui envoie occasionnellement une requête ping aux serveurs peut créer une liste de serveurs potentiellement indisponibles, évitant ainsi de longs temps d'arrêt.
4 Réglage des paramètres exposé par l'API
Certaines bibliothèques fournissent des moyens explicites d'affecter les performances (par exemple, en contrôlant la taille des tampons alloués aux fichiers, la taille initiale des tables ou la taille des caches), et le système d'exploitation propose également des options de réglage. Le réglage de ces paramètres peut améliorer les performances dans les limites des conventions de performances. Le réglage ne peut pas résoudre le problème global, mais peut réduire les options fixes intégrées dans la bibliothèque, ce qui peut sérieusement affecter les performances.
Certaines bibliothèques proposent des implémentations alternatives de fonctions avec la même sémantique, généralement des implémentations concrètes de l'API générique. Le réglage en choisissant la meilleure implémentation concrète est souvent très simple, et les collections Java sont un bon exemple de cette structure.
De plus en plus, les API sont conçues pour s'adapter dynamiquement à l'application, libérant ainsi le programmeur de la nécessité de choisir les meilleurs paramètres. Si une table de hachage est trop pleine, elle est automatiquement étendue et remaniée (un avantage, mais parfois un impact sur les performances). Si le fichier est lu séquentiellement, davantage de tampons peuvent être alloués pour une lecture en morceaux plus gros.
5 Mesurer les performances pour tester les hypothèses
Une approche courante consiste à instrumenter les structures de données critiques pour déterminer si chaque structure est utilisée correctement. Par exemple, vous pouvez mesurer le degré d'exhaustivité d'une table de hachage ou la fréquence à laquelle des collisions de hachage se produisent. Alternativement, il est possible de vérifier qu'une structure qui est rapide à lire au détriment des performances d'écriture est en réalité lue plus souvent qu'elle n'est écrite.
Rien de tout cela n’empêche les perfectionnistes de développer des outils pour automatiser les tableaux de bord et les mesures, ou de développer des méthodes pour détailler les conventions de performance afin que les mesures de performance puissent établir le respect des conventions de performance. Ces objectifs ne seront pas faciles à atteindre et les récompenses pourraient ne pas être grandes.
Les mesures de performances peuvent souvent être effectuées sans instrumenter le logiciel au préalable, avec l'avantage qu'aucun travail n'est requis avant de devoir détecter un problème. Cela peut également aider à diagnostiquer les problèmes qui surviennent lorsque des modifications apportées au code ou aux bibliothèques affectent les performances. Exécutez régulièrement un profilage pour mesurer les écarts de performances de manière fiable.
6 Détecter et consigner les anomalies à l'aide des journaux
Lorsque les services distribués composent un système complexe, les violations des contrats de performance se multiplient. Notez que les services fournis sur les interfaces réseau ont parfois des SLA spécifiant des performances acceptables. Dans de nombreuses configurations, le processus de mesure effectue des demandes de service occasionnelles pour vérifier que les SLA sont respectés. Étant donné que ces services utilisent des méthodes similaires aux appels d'API (par exemple, les appels de procédure à distance ou leurs variantes telles que XML-RPC, SOAP ou REST), il peut y avoir des attentes en matière de contrat de performance. L'application détecte la défaillance de ces services et répond généralement de manière appropriée.
Cependant, une réactivité lente, en particulier lorsque de nombreux services dépendent les uns des autres, peut très rapidement nuire aux performances du système. Il serait utile que les clients de ces services puissent documenter les performances qu'ils attendent et générer des journaux permettant de diagnostiquer les problèmes (c'est l'une des utilisations de syslog). Lorsque les sauvegardes de fichiers semblent excessivement lentes, sont-elles plus lentes qu’hier ? Plus lent qu'avant la dernière mise à jour du logiciel du système d'exploitation ? Est-il plus lent que prévu étant donné le périphérique de sauvegarde qui peut être partagé par plusieurs ordinateurs ? Ou existe-t-il une explication plausible (par exemple, le système de sauvegarde découvre une structure de données corrompue et démarre un long processus pour la reconstruire) ?
Le diagnostic des problèmes de performances dans les compositions logicielles opaques peut être utile pour signaler les performances et détecter les problèmes en l'absence de code source et de détails sur les modules et les API qui composent la composition. Bien que les problèmes de performances ne puissent pas être résolus au sein du logiciel, des modifications ou des correctifs peuvent être apportés au système d'exploitation et au réseau. Si le périphérique de sauvegarde est lent parce que le disque est presque plein, ajoutez définitivement plus d'espace disque. Une bonne journalisation et les outils associés sont utiles ; malheureusement, la journalisation peut être un domaine sous-évalué et négligé dans l’évolution des systèmes informatiques.
Certes, le contrat de performance est moins important que le contrat d’exactitude fonctionnelle, mais la quasi-totalité de l’expérience utilisateur importante d’un système logiciel en dépend.