Question

Je teste une application Web .NET.J'ai fait cela pour 2 raisons :Je voulais voir à quoi ressemblaient les performances dans des conditions réelles et aussi m'assurer que nous n'avions manqué aucun problème lors des tests.Nous avions 30 utilisateurs simultanés dans l'application qui l'utilisaient comme ils le feraient dans le cadre normal de leur travail.La plupart des utilisateurs avaient plusieurs fenêtres de l’application ouvertes.

  • 10 utilisateurs :Pas mal
  • 20 utilisateurs :Ralentir
  • 30 utilisateurs :Très, très lent mais pas de timeout

Il a été chargé sur le serveur de production.Il s'agit d'un serveur virtuel doté d'un processeur Xeon 2,66 GHz et de 2 Go de RAM.Nous utilisons Win2K3 SP2.Nous avons chargé .NET 1.1 et 2.0 et utilisons SQLExpress SP1.

Nous avons revérifié les index de toutes les tables par la suite et ils étaient tous comme ils devraient l'être.

Comment pouvons-nous améliorer les performances de notre application ?

Était-ce utile?

La solution

C'est juste quelque chose auquel j'ai pensé, mais vérifiez la quantité de mémoire utilisée par SQL Server lorsque vous avez plus de 20 utilisateurs - l'une des limitations de la version Express est qu'elle est limité à 1 Go de RAM.Il se peut donc qu'il s'agisse simplement d'un manque de mémoire disponible pour le serveur en raison des limitations d'Express.

Autres conseils

  1. Vous pouvez rencontrer des problèmes de concurrence, selon la manière dont votre application s'exécute.Essayez d'effectuer vos lectures avec le mot-clé "nolock".

  2. Essayez d'ajouter des alias de table pour vos colonnes (et évitez d'utiliser SELECT *), cela aide MSSQL, car il n'a pas besoin de "deviner" de quelle table proviennent les colonnes.

  3. Si ce n'est pas déjà fait, passez aux SPROC, cela permet à MSSQL de mieux indexer vos données pour le jeu de résultats normal d'une requête donnée.

  4. Essayez de suivre le plan d'exécution de votre SPROCS pour vous assurer qu'ils utilisent les index que vous pensez.

  5. Exécutez une trace sur votre base de données pour voir à quoi ressemblent les demandes entrantes.Vous remarquerez peut-être qu'un SPROC particulier est exécuté encore et encore :généralement un bon signe pour mettre en cache les réponses sur le client si possible.(listes de recherche, etc.)

Mise à jour:Il semble que SQL Server Express ne soit pas le problème car ils utilisaient le même produit dans la version précédente de l'application.Je pense que la prochaine étape consiste à identifier les goulots d'étranglement.Si vous êtes sûr qu'il se trouve dans la couche base de données, je vous recommande de prendre une trace du profileur et de réduire le temps d'exécution des requêtes les plus coûteuses.

Il s'agit d'un autre lien que j'utilise pour collecter des statistiques à partir des vues de gestion dynamique (DMV) de SQL Server et des fonctions de gestion dynamique (DMF) associées.Je ne sais pas si nous pouvons l'utiliser dans l'édition Express.Découvrez les données cachées pour optimiser les performances des applications.


Utilisez-vous SQL Server Express pour une application Web ?Pour autant que je sache, il présente certaines limites pour le déploiement en production.

SQL Server Express est gratuit et peut être redistribué par les éditeurs de logiciels indépendants (sous réserve d'accord). SQL Server Express est idéal pour apprendre et créer des applications de bureau et de petits serveurs.Cette édition constitue le meilleur choix pour les éditeurs de logiciels indépendants, les développeurs non professionnels et les amateurs créant des applications client.Si vous avez besoin de fonctionnalités de base de données plus avancées, SQL Server Express peut être mis à niveau de manière transparente vers des versions plus sophistiquées de SQL Server.

Je vérifierais les performances du disque sur le serveur virtuel.Si c'est l'un des problèmes, je recommanderais de placer la base de données sur une broche distincte.

Mise à jour:Passez à une broche séparée ou mettez à niveau la version de SQL Server comme le suggère à juste titre Gulzar.

assurez-vous de fermer les connexions après avoir récupéré les données.

Exécutez SQL Profiler pour voir les requêtes envoyées à la base de données.Recherchez les requêtes :

  • renvoyer trop de données
  • mal construit
  • sont exécutés trop de fois
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top