1. les performances
La gestion de la performance des applications reste une priorité pour les entreprises. En particulier sur les architectures trois-tiers ou si vous préféres les architectures « web » où l’on est passé d’applications peu sensibles à des applications transactionnelles critiques.
Aujourd’hui, même si les solutions multi-tiers permettent la mise en place de fermes de serveurs pouvant supporter la charge, la nécessité de réduire le coût hardware / licences favorise la recherche de la performance par processeur.
De ce point de vue, la performance délivrée par ASP.NET n’a plus grand-chose à voir avec son prédécesseur. En particulier, ASP.NET exploite au mieux la présence d’un grand nombre de processeurs.
2. La Pré-compilation et la gestion du cache
L’amélioration de la performance des applications ASP.NET est liée à un certain nombre de facteurs, qu’il est important de comprendre pour bien discerner la valeur ajoutée du Framework.
Les pages ASP.NET, à la différence de la génération précédente des pages ASP, sont compilées lors de leur première version sous forme d’assemblies, assemblies qui remplacent les DLL.
Autrement dit, dès le second appel d’une page ASP.NET, la performance est identique à celle d’un objet compilé. C’est réellement une amélioration considérable.
Mais l’amélioration de la performance tient pour beaucoup à la mise à disposition d’un ensemble de solutions de « cache ».
Le principe du cache est de ne pas recalculer un élément si celui-ci a déjà été demandé antérieurement, pour le délivrer directement.
Le cache qui était en partie mis en œuvre en ASP 3.0 et a été considérablement revu. Il permet d’agir avec une grande précision et reste compatible avec le déploiement de fermes de serveurs, sans développement complémentaire. Le gain de temps pour le développeur est important. A la clé, des gains de performance plus que sensibles.
Le cache peut-être décomposé en plusieurs sous-ensembles, rassemblés comme ci-dessous.
Le cache de page : il permet, pour tout ou partie de la page, de « cacher » le résultat envoyé au client comme s’il s’agissait d’une page statique. Un certain nombre de paramètres permettent de définir dans quelles conditions il faut rafraîchir le résultat renvoyé.
Le cache applicatif : ce sont les objets Session et Application (qui existaient déjà mais qui ont été largement revus, notamment pour supporter le load-balancing et les fermes de serveur), et surtout l’objet Cache. Ce dernier permet de stocker des données ou des objets à durée de vie limitée, l’expiration du cache associé pouvant s’appuyer sur des priorités, des dépendances entre objets, des règles définies par le développeur, etc. L’objet cache supporte les fermes de serveurs et les accès multi-threadés, de manière transparente pour le développeur.
Les variables statiques de classe : il s’agit d’un mécanisme fort intéressant, mais que je ne détaillerai pas ici ; il reste à manipuler avec prudence, notamment pour gérer les accès multi-threadés.
Le framework met à disposition des développeurs des outils de cache très puissants, qui demandent toutefois une certaine pratique pour être mis en œuvre correctement et dégager toute leur valeur ajoutée.
Sources :
ASP.Net micro application référence (frédérik ducrozet – guillaume coffin)
ASP.Net microsoft press (richard clark)
Passage à .NET : quels gains pour l’entreprise ? (Business Interactif )
Forum |
Actu |
Glossaire |
Codes |
Tips |
Liens |
Livres |
Annuaire
