Comment optimiser l'évolutivité des applications Web ASP.NET

Par Iqbal Khan

Comment assurer le bon fonctionnement de vos applications Web lorsque les charges de travail augmentent.

Les applications Web basées sur la technologie Microsoft ASP.NET sont de plus en plus utilisées dans des environnements à transactions élevées avec des milliers d'utilisateurs. Par conséquent, ces applications sont hébergées dans des fermes Web composées de plusieurs serveurs Web avec un équilibreur de charge.

Avec cette charge accrue, de nombreuses applications connaissent des goulots d'étranglement majeurs en termes de performances et d'évolutivité. Les chefs d'entreprise sont déjà aux prises avec ces problèmes ou sont, sans le savoir, sur la voie rapide pour s'écraser directement dans ces zones troublées. L'évolutivité signifie conserver les mêmes performances même pendant les heures de pointe ou tout en prenant en charge un plus grand nombre d'utilisateurs en général.

Les goulots d'étranglement habituels de l'évolutivité surviennent lorsqu'une application doit assumer plus de charge utilisateur, ce qui augmente les déplacements coûteux vers la base de données ou tout autre magasin de données, et ce magasin de données devient un goulot d'étranglement et entraîne une baisse drastique des performances de l'application.

Il existe deux types de données dans les applications ASP.NET qui provoquent ces goulots d'étranglement. L’un concerne les données de session utilisateur ; l'autre concerne les données d'application. Les données de session utilisateur sont stockées dans State Server ou SQL Server fourni par Microsoft. Les données applicatives sont stockées dans une base de données relationnelle (Oracle, SQL Server, DB2, etc.).

L’utilisation d’un cache distribué en mémoire supprime facilement les goulots d’étranglement pour ces deux types de données. Pour les sessions utilisateur, le cache distribué peut être intégré sans aucun effort de programmation et via un module de plug-in logiciel et remplace les options de stockage de session utilisateur existantes.

Cependant, pour les données d'application, un cache distribué ne remplace pas une base de données relationnelle, mais ne fait que l'augmenter en contribuant à réduire les déplacements coûteux vers celle-ci. L'intégration d'un cache distribué nécessite ici quelques petites quantités de programmation pour appeler l'API du cache.