Discussion :

[DotNetMatt]

Bonjour,

Voilà plusieurs jours que je réfléchis à la manière la plus efficace de gérer le cache dans mon application ASP.NET, mais je n'arrive pas à me décider. Peut-être pourrez-vous m'apporter quelques éclairages, notamment en terme de performances.

Voici le contexte. Je travaille sur une grosse application permettant de gérer des documents et des processus commerciaux. En ce moment, je suis plus particulièrement sur la partie Rapports, qui doit permettre aux utilisateurs de pouvoir afficher des statistiques et des graphiques.

Pour récupérer ces informations, j'utilise Linq2SQL avec un modèle de base de donnée (fichier .DBML). Dans ce modèle, j'utilise une procédure stockée qui s'appelle GetAllOpportunities(), et qui me permet de récupérer l'ensemble des informations dont j'ai besoin (on parle de plusieurs milliers de lignes).

Ce que je fais pour l'instant, c'est lorsque l'utilisateur demande un rapport, je récupère le contenu de GetAllOpportunities, puis je place tout ça dans le cache pendant 15 minutes, et j'effectue mes calculs depuis le cache ASP.NET.

Est-ce que vous pensez que c'est une bonne approche ? Est-ce qu'en terme de performances, il ne serait pas mieux de faire faire les calculs par SQL Server ?

Merci par avance pour vos éclairages

[Nicolas Esprit]

Bonjour,

Cela dépend comment sont dimensionnés tes serveurs. Générlement un serveur SGBD est mieux fourni en RAM et cores CPU que le ou les serveurs Web. Donc réaliser les calculs sur la DB plutôt que dans ton appli ASP.NET sera plus conseillé.

Cela dépend aussi des traitements que tu réalises et à quelle fréquence. Si tu dois faire une opération genre "conversion du prix en devise" => refaire une requête au SGBD sur plusieurs milliers de lignes pour ce simple calcul est contre-performant.

Sans plus de détails, difficile de t'aider plus.

Sache aussi que si tu as du mal à déterminer ce qui est le mieux, il reste toujours une solution : le test ! Tu peux facilement réaliser avec Visual Studio 2010 un teste de charge en simulant une grande quantité d'utilisateurs sur un scénario par exemple. A défaut, il existe des tools pour cela, ou encore tu peux le coder toi même avec des HttpWebRequest/HttpWebResponse.

En espérant t'avoir aidé.

[DotNetMatt]

En fait sur chacun des rapports, je dois calculer de nombreuses choses, bien souvent avec plusieurs calculs intermédiaires, ce qui nécessite l'utilisation des mêmes données plusieurs fois.

Je dois faire des calculs de marge, des calculs de coût de revient, des classements, etc. Bref je ne vais pas trop donner de détails car je pense que ça ne servira à rien, et puis ce n'est pas à vous de faire tout le boulot à ma place

Ma question était plutôt de savoir s'il vallait mieux utiliser le cache ASP.NET ou SQL Server pour effectuer ces calculs. Et tu as répondu à ma question, car nos serveurs de prod SQL Server sont effectivement plus costauds que les serveurs de prod IIS donc je pense que je vais leur déléguer ces opérations.

Je n'avais pas pensé à utiliser les outils de Visual Studio pour simuler une grosse charge, je vais y jeter un oeil.

Merci

[Nicolas Esprit]

Vu que tu réalises des opérations multiples, le traitement via SQL n'est peut être pas le plus pratique en terme de développement. Mais comme tu utilises SQL Server, tu peux toujours utiliser des procédures stockées CLR ( donc du C# mais côté SQL Server avec le CLR enabled).

Autre solution pour soulager ton serveur web : un service. Par exemple, sur des projets où il y avait beaucoup de données à traiter, on utilisait un service windows ( un serveur web pour les applications ASP.NET et Web Services, un serveur SQL Server et un serveur applicatif où tournait le service windows). La communication se faisait via .NET Remoting (le binaire étant toujours plus performant que du XML).
L'autre avantage est que si plusieurs applications ont besoin des mêmes données ou même traitements (un web service pour l'utilisation dans Excel + une application ASP.NET + une WPF par exemple), tu centralises le tout (coup de dev et maintenance réduit, meilleur monitoring, etc...).

En espérant t'avoir aidé.

[DotNetMatt]

J'ai regardé du côté de SQL CLR, et ça m'a l'air pas mal pour mes besoins !

Dans un premier temps j'avais aussi pensé à mettre un serveur dédié qui héberge le service de génération, mais lorsque j'ai soumis l'idée à mon responsable il m'a rétorqué que comme on ne génère que 5 rapports différents on pouvait sûrement faire autrement... Soit.

Donc voilà je pars du côté des procédures stockées CLR, ça m'a l'air plutôt adapté à ce dont j'ai besoin On verra ce que ça donne.

Merci pour ces tuyaux !

[Nicolas Esprit]

Oui, comme je le disais, les choix dépendent de l'architecture et du budget. Mettre en place un nouveau serveur uniquement pour 5 reports....

Sinon petite mise en garde pour les prod stock en CLR => attention à la gestion de la mémoire ! Pense bien à utiliser des using à outrance et si besoin appeller Dispose. A part ça, ça reste du développement standard.

Aussi, vois avec tes DBA s'ils veulent bien activer le CLR (pas activé par défaut je crois). Certains DBA sont réticents à ce sujet (car ils méconnaissent surtout).