Application de test

Préambule

1. Une migration historique

Avant de commencer à explorer notre application de test dans ce chapitre, il convient de donner quelques explications sur cette dernière.

Cet ouvrage est la seconde édition et, à cet effet, beaucoup de choses ont changé depuis la première édition sortie en 2011. De ce fait, les chapitres précédents ont été actualisés sur un plan théorique, mais il fallait également actualiser l’application de test afin de refléter les usages modernes.

L’application initiale était une solution composée de deux parties : un webservice ASMX et une application WinForms cliente. Bien que ces technologies existent encore de nos jours, leur utilisation conjointe ne constitue clairement plus un cas d’usage répandu (et si tel est le cas, il doit s’agir davantage de maintenance que de création). Cependant, si ce cas d’usage vous intéresse plus que l’actuel, l’auteur vous recommande de vous procurer la première édition de cet ouvrage, plus adaptée.

Néanmoins, le concept de « client-serveur » perdure toujours, même si aujourd’hui on parlera plutôt de « front-end » et « back-end ». À cet effet, le webservice ASMX a été migré en ASP.NET...

Critères de choix

1. Pourquoi cette application ?

Comme cela a déjà été plusieurs fois expliqué auparavant, la philosophie de ce livre n’est pas d’expliquer de manière experte tous les mécanismes internes de .NET ni d’analyser toutes les fines optimisations possibles de la performance, mais de montrer les causes les plus habituelles de dégradation de performance dans des applications .NET. Les causes sont parfois simples, mais trouver le point bloquant précis à partir des symptômes rencontrés est souvent plus complexe. L’idée ici n’est donc pas de faire du tuning, mais de montrer les cas typiques de programmation incorrecte aboutissant à des performances dégradées.

Cela étant posé, il est apparu évident que l’application de démonstration ne pouvait pas être basée sur autre chose qu’un vrai logiciel industriel. Après avoir autant insisté sur le fait que nous devons nous attaquer aux causes réelles, en nous éloignant du point de vue académique, il aurait été malvenu de proposer d’appliquer les méthodes de profilage sur une application de test sans aucun lien avec la réalité.

À cet effet, dans le cadre de la seconde édition, un effort tout particulier a été apporté afin de conserver au maximum tels quels les différents objets et routines métier qui étaient présents dans la première édition. Néanmoins, le changement de technologie a impliqué quelques modifications, où l’auteur a introduit les erreurs de programmation les plus courantes.

2. Utiliser des retours d’expérience

L’utilisation d’une vraie application présente également l’avantage de ne pas avoir à imaginer...

Application choisie

1. Domaine d’utilisation

L’application choisie, ou plutôt la plate-forme choisie pour les démonstrations, car il s’agit d’une plate-forme commune à plusieurs applications, est basée sur .NET 6. La première application utilisant cette plate-forme est une application de gestion tout ce qu’il y a de plus traditionnelle, utilisant des fiches et un système de parcours d’information, le tout agrémenté de modules de reporting, de traitement en masse, etc. La seconde application utilise le même système pour mettre à disposition de l’utilisateur des moteurs de modélisation de calculs budgétaires plus complexes.

2. Architecture

De manière globale, la plate-forme permet de créer des applications composées d’un client Blazor WebAssembly communiquant avec une WebAPI ASP.NET contenant le métier, elle-même en relation avec des bases de données par un mécanisme multibase utilisant directement ADO.NET. Il s’agit ici d’une mutation de l’architecture initiale, qui se verra être transformée au fur et à mesure des avancées pour arriver sur des standards de code modernes.

3. Interface

Le but du livre est de montrer des structures de code et d’architecture de solution peu performantes. Il était donc hors de question d’encombrer...

Détail de l’application

1. Trouver l’application

L’auteur recommande, pour bien comprendre la suite, de prendre quelques minutes pour bien s’imprégner de l’application de test. Celle-ci, répondant au nom de PROFI, peut être téléchargée sur le site des Éditions ENI ou est disponible directement sur GitHub à l’adresse suivante : https://github.com/hybrid-technologies-solutions/eni-dotnet-perf/tree/main/AvantOptimisation (attention à bien prendre la version dans le dossier AvantOptimisation et non ApresOptimisation).

Au risque de répétition, l’application cible est une sorte d’anti-patron global de code de la performance. Un œil exercé se rendra vite compte qu’elle est codée de manière catastrophique. C’est là le but : cette application doit reprendre tous les problèmes de performance et ajouter en plus tous les autres cas standards que l’auteur souhaite faire apparaître par le profilage. Le lecteur est donc invité à retenir son indignation potentielle en étudiant son code et son fonctionnement, car c’est normal, PROFI doit être le reflet de toutes les mauvaises pratiques de codage.

2. Installation de la base de données

Dans le but de simplifier le travail d’installation de la base de données, l’auteur propose plusieurs approches, parmi lesquelles le lecteur pourra choisir celle qui lui paraît la plus simple à mettre en œuvre. Afin que l’application ne soit pas limitée par les performances du SGBD, SQL Server a été retenu comme base de données. Il est à noter que SQL Server peut librement être lancé sur n’importe quel ordinateur pouvant exécuter Docker.

Pour cela, il faut procéder ainsi :

Installer Docker sur le système.
Lancer un conteneur contenant l’image en exécutant la commande suivante :

docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=10mdpAdmin !" -p 
1433 :1433 -d mcr.microsoft.com/mssql/server :2019-latest

Une fois ces deux étapes exécutées, un conteneur faisant tourner SQL Server aura été monté et sera accessible localement sur le port 1433.

Si le lecteur a déjà installé...

Explication de la lourdeur de l’application

Peut-être le lecteur se sera-t-il fait la remarque que, pour une application de simple démonstration, le découpage en nombreux projets, l’architecture du client séparant les contrôles Blazor, etc. sont très lourds. Nous sommes bien loin des bonnes pratiques Agile de simplicité des développements.

Il est vrai qu’en théorie, si nous avions juste voulu créer une application pour réaliser le peu de besoin métier exposé dans PROFI, il aurait été possible de créer simplement un exécutable avec tout le code en dur et une API contenant le métier et les accès à la base de données. Une autre possibilité aurait été de réaliser la totalité en Blazor Server, ce dernier s’exécutant sur le serveur nous donnant la possibilité d’accéder directement à la base de données. Si l’application ne devait vraiment faire qu’afficher des personnes et des contrats, les méthodes Agile recommandent de produire le code le plus simple possible et clairement, le code présent constituerait alors une sur-architecture énorme.

Mais il y a une bonne raison derrière cette apparente surpondération du code de l’application : PROFI s’inspire d’une vraie application...

Méthode recommandée

Pendant la lecture des prochains chapitres, où nous allons décortiquer les différents points sensibles relatifs à la performance de cette application cible, il sera important de garder en tête quelques principes de travail, en plus des principes de base du profilage tels qu’ils ont été posés en introduction.

Le premier principe est de ne jamais faire confiance à son instinct de développeur en ce qui concerne la performance. Il sera montré abondamment que ce que nous pensons être un goulet ne pose souvent pas de problème, et que ce qui doit diriger la réduction des performances est une confiance aveugle dans les outils nous permettant de vérifier.

Le second principe, pour la mise en œuvre des solutions, est de toujours penser en termes de simplicité. Les problèmes de performance d’une application viennent du fait que, pour réaliser une opération "métier", l’ordinateur doit effectuer plus d’opérations "atomiques" que ce qu’il est réellement nécessaire. Il est important de toujours faire la différence entre la complexité algorithmique et la complexité réelle du problème. La première ne doit pas être plus élevée que la seconde. Le réflexe de la réarchitecture...