J'ai une question de performance ado.net/tsql. Nous avons deux options dans notre application:
1) Un grand appel de base de données avec plusieurs ensembles de résultats, puis dans le code étape par chaque ensemble de résultats et peupler mes objets. Cela entraîne un aller-retour à la base de données.
2) plusieurs petits appels de base de données.
Il y a beaucoup plus de réutilisation de code avec l'option 2 qui constitue un avantage de cette option. Mais j'aimerais avoir une contribution sur le coût de la performance. Deux petits voyages rondes sont-ils deux fois plus lents que d'un grand voyage aller-retour à la base de données ou est-ce juste une petite perte de performance de 10%? Nous utilisons C # 3.5 et SQL Server 2008 avec des procédures stockées et Ado.net.
8 Réponses :
Si vous êtes en préoccupé par la performance, essayez un test des deux et voyez qui fonctionne mieux.
Personnellement, je préfère la deuxième méthode. Cela facilite la vie des développeurs, rend le code plus réutilisable et modularise les choses afin que les modifications apportées à la route sont plus faciles.
Personnellement, j'irais avec 1 aller-retour plus grand.
Cela sera définitivement influencé par la réutilisabilité exacte du code d'appel et comment il pourrait être refactored.
Mais comme mentionné, cela dépendra de votre situation exacte, où la maintenabilité vs la performance pourrait être un facteur.
J'aime personnellement l'option deux pour la raison pour laquelle vous avez indiqué: Mais considérez ceci: pour les petites demandes, la latence pourrait être plus longue que ce que vous faites avec la demande. Vous devez trouver ce bon équilibre.
Ne pas Optimiser pour la performance jusqu'à ce que le besoin de le faire. Cela signifie que vous devez analyser vos habitudes d'utilisation anticipées et déterminer la fréquence typique de l'utilisation de ce processus et quelle latence d'interface utilisateur résultera de la présente conception. Si l'utilisateur recevra des commentaires de l'application est inférieur à quelques secondes (2-3) secondes, et la charge de l'application à partir de ce processus n'est pas une charge démesurée sur la capacité du serveur, puis ne vous inquiétez pas. Si OTOH, l'utilisateur attend une quantité de temps inacceptable pour une réponse (sujette mais définitivement mesurable) ou si le serveur est surchargé, il est temps de commencer l'optimisation. Et ensuite, quelles techniques d'optimisation auront le plus de sens, ou être la plus rentable, dépendent de votre analyse de la question.
Donc, entre-temps, concentrez-vous sur la maintenabilité. Cela signifie, dans votre cas, code de réutilisation
En tant que développeur Ado.net, votre travail consiste à rendre le code aussi correct, clair et maintenu le plus possible possible. Cela signifie que vous devez séparer vos préoccupations.
C'est le travail de la technologie de connexion SQL Server pour le rendre rapide.
Si vous mettez en place une application correcte, claire et maintenable qui résout les problèmes d'entreprise, il s'avère que l'accès à la base de données est le principal goulot d'étranglement qui empêche le système de fonctionner dans des limites acceptables, et seulement à ce moment-là, devriez-vous commencer persuader les moyens de résoudre le problème. Cela peut ou non inclure la consolidation des requêtes de base de données.
Je penserais que cela dépendrait en partie lorsque vous avez besoin des données. Par exemple, si vous retournez dix jeux de données dans un grand processus et voyez tous les dix à l'écran à la fois, alors allez-y. Mais si vous retournez dix jeux de données et que l'utilisateur ne peut cliquer que dans les pages pour en voir trois d'entre eux, l'envoi des autres était un gaspillage de ressources de serveur et de réseau. Si vous retournez dix jeux de données, mais l'utilisateur doit vraiment voir les ensembles sept et huit seulement après avoir modifié les ensembles 5 et 6, alors l'utilisateur verrait les mauvaises informations si vous l'avez renvoyé trop tôt.
Si vous utilisez des Procs stockés distincts pour chaque ensemble de données appelé dans un procédé maître stocké, il n'y a aucune raison pour laquelle vous ne pouvez pas réutiliser le code ailleurs, donc la réutilisation du code n'est pas vraiment un problème dans mon esprit.
Cela semble un peu évident évident, mais envoyez uniquement ce dont vous avez besoin dans un appel.
Par exemple, nous avons un processus stocké "getSttuff" pour la présentation. "UpdaStuff" proc appelle "getSttuff" Proc et la méthode de wrapper du client pour "UpdaTestuff" s'attend à ce que le type "chose". Donc, un aller-retour.
Les serveurs de chatty sont une chose que vous empêchez à l'avance avec un effort minimal. Ensuite, vous pouvez régler le code DB ou le code client selon vos besoins ... mais il est difficile de prendre en compte les aller-retour plus tard, peu importe la rapidité avec laquelle votre code fonctionne. À l'extrême, que se passe-t-il si votre serveur Web est dans un pays différent de votre serveur DB ...?
Edit: Il est intéressant de noter les gars SQL (HLGEM, Astander, ME) en disant "un voyage" et les gars du client disant "multiple, réutilisation de code" ...
Je me bats avec ce problème moi-même. Et je n'ai pas de réponse, mais j'ai quelques pensées.
Après avoir examiné les réponses données par d'autres à ce point, il y a encore une troisième option.
Dans mon appllication, environ dix ou douze appels sont faits au serveur pour obtenir les données dont j'ai besoin. Certaines des zones de données sont varchar champs max et varbinary max (images, documents volumineux, vidéos et fichiers audio). Tous mes appels sont synchrones - à savoir, alors que les données sont demandées, l'utilisateur (et le programme côté client) n'a pas d'autre choix que d'attendre. Il ne peut vouloir lire ou afficher les données qui n'a de sens que tout quand il est là, pas seulement en partie là. Le processus, je crois, est plus lent de cette façon et je suis en train de développer une autre approche qui est basée sur les appels asynchrones au serveur à partir d'une libaray DLL qui déclenche des événements au client d'annoncer les progrès au client. Le client est programmé pour gérer les événements de DLL et définir une variable sur le côté client indiquant les appels chich ont été complétées. Le programme client peut alors faire ce qu'il doit faire pour préparer les données reçues dans l'appel # 1 alors que la DLL se poursuit de manière asynchrone pour obtenir les données d'appel # 2. Lorsque le client est prêt à traiter les données d'appel n ° 2, il doit vérifier l'état et attendre de procéder si nécessaire (j'espère que ce sera un peu ou pas du tout attendre). De cette manière, le serveur et le logiciel côté client sont l'exécution du travail d'une manière plus efficace.
Avez-vous mis en place la mise en commun de la connexion?