Parfois, nos applications Web sont très rapides lorsqu'elles sont testées localement, mais lorsqu'elles sont testées sur le LAN, des problèmes de performances seront parfois détectés sur le WAN ; Ces problèmes sont généralement dus à une négligence ou à des erreurs dans l'application et n'impliquent pas l'architecture du système. Le problème peut être détecté et résolu grâce au débogage et aux tests dans l'environnement réel.
Ce dont nous parlons aujourd'hui, c'est d'améliorer fondamentalement les performances des applications ASP.Net en améliorant l'architecture.
Testons d'abord quelques applications simples d'ASP.Net.
Environnement de test : AthlonXP 3200+, DDR400 512M, WindowsXP SP2, SQL Server 2000 natif, table des produits de la base de données Northwind chinoise (importée depuis Access), environ 70 enregistrements.
| Numéro de série du test | Type de programme | Méthode de test | Résultat du test (Requêtes par seconde) | SQLServer Ressources occupées | ASP.Net Ressources occupées |
| 1 | Le service Web | remplit le DataSet avec la table produit et renvoie le nombre d'enregistrements | 250 fois | 100% | - |
| 2 | Le service Web | remplit le DataSet avec la table produit et renvoie le DataSet | 138 fois | 54% | 46% |
| 3 | L'application Web | remplit le DataSet avec la table des produits et renvoie Bind DataGrid | 70 fois | 28 % | 72 % |
Dans le premier test, le service Web lit uniquement les enregistrements de la base de données, les remplit dans le DataSet et renvoie le nombre d'enregistrements (notez qu'il ne renvoie pas d'enregistrements). Il est supposé que le système occupe très peu de ressources. les ressources sont entièrement occupées par SQL Server et la conclusion n'est pas claire. Il y aura des effets négatifs.
Dans le deuxième test, lorsque le service Web renvoie un DataSet, le nombre de requêtes par seconde est réduit de près de moitié. La moitié des ressources système est utilisée par ASP.Net pour sérialiser le DataSet.
Dans le troisième test, où l'application Web lie le DataSet au DataGrid et renvoie la page, le nombre de requêtes par seconde est réduit de près des trois quarts. Ces ressources système sont utilisées par ASP.Net pour lier le DataSet au DataGrid. et renvoyez la page. Sérialisez la page.
D'après les tests ci-dessus, nous pouvons voir que la liaison et la sérialisation de DataGrid occuperont beaucoup de ressources système. Si vous souhaitez améliorer les performances du système, vous devez améliorer l'architecture.
1. Séparez les opérations sur la base de données de la page et placez-les dans une couche de persistance indépendante.
De cette manière, les données sont affichées sous forme de tableau via DOM ou XSLT côté client, remplaçant le travail de liaison du DataGrid côté serveur, ce qui réduit considérablement la pression sur le serveur. Et le client obtient les données de la couche de persistance via AJAX, ce qui améliorera l'expérience utilisateur.
2. Séparez complètement la page des données afin que le cache puisse être utilisé.
Certaines pages qui appliquent AJAX liront toujours les données initiales, la page ne pourra donc pas être mise en cache. Ces pages sont généralement plus complexes et occupent plus de ressources que les pages ordinaires. Si le cache peut être utilisé, les performances du système seront encore améliorées.
Grâce aux deux points ci-dessus, les performances d'ASP.Net peuvent être presque doublées.
Vous pouvez le tester vous-même ou visiter notre exemple www.BizStruct.cn .