Performances SQL Server ADO.NET: plusieurs jeux de résultats et plusieurs exécutions de commandes

Question

Avec la mise en pool de connexions ou au moins l'hypothèse que la connexion n'est pas fermée entre les appels, existe-t-il une différence de performances réseau et serveur? exécution de procédure stockée avec plusieurs jeux de résultats et plusieurs exécutions de procédure stockée.

Dans le code pseudo, quelque chose comme

using(new connection) 
{ 
    using (datareader dr = connection.Execute(Command)) 
    { 
    while (dr.NextResult()) 
    { 
     while (dr.Read()) 
     { 
     SomeContainer.Add(Something.Parse(dr)); 
     } 
    } 
    } 
} 

vs

using(new connection) 
{ 
    using (datareader dr = connection.Execute(Command)) 
    { 
    while (dr.Read()) 
    { 
     SomeContainer.Add(Something.Parse(dr)); 
    } 
    } 

    using (datareader dr = connection.Execute(Command)) 
    { 
    while (dr.Read()) 
    { 
     SomeContainer.Add(Something.Parse(dr)); 
    } 
    } 
} 

Answer 1

Le premier est un aller-retour au serveur, le second est des allers-retours distincts. Un aller-retour se produit une pénalité due à la latence du réseau, le temps d'analyser la requête, le temps de mettre en place un contexte d'exécution, etc. Cependant, cette pénalité est négligeable pour tout sauf les applications les plus critiques. Donc, faites tout ce qui est plus facile à comprendre, à coder, à mettre au point et à maintenir (à mon humble avis, ce serait la deuxième option). Vous ne serez probablement pas en mesure de mesurer la différence.

Answer 2

Je ne suis pas d'accord, j'irais presque toujours avec la 1ère approche (cela dépend vraiment du scénario particulier) mais en général, il vaut mieux avoir un proc renvoyant 2 ensembles de résultats plutôt que 2 appels à 2 processus différents retourner un seul ensemble de données précisément pour les raisons expliquées par @Remus (latence du réseau, etc).

Dans la majorité des cas, la différence n'est pas négligeable.

Answer 3

Suggérez-vous de profiler la différence par vous-même. Ce qui est le plus efficace peut dépendre beaucoup de la quantité de données et combien d'utilisateurs etc. J'aurais tendance à croire que le voyage aller-retour sur le réseau est meilleur, mais il est préférable d'essayer les deux approches et mesurer.

Answer 4

Vous pouvez supposer que le regroupement de connexions est utilisé dans vos deux scénarios, donc c'est vraiment un facteur non-déterminant dans votre détermination de l'efficacité.

Si vous pouvez recevoir tous les résultats en un seul appel, il est naturellement plus efficace que plusieurs appels. Considérez le cas simple de la sélection de 10 choses individuellement par rapport à la sélection des 10 à la fois avec une clause 'in'. C'est 1 requête envoyée au serveur et 1 réponse analysée vs 10 de chaque. C'est l'aller-retour dont parle Remus.

Il s'agit très probablement d'une utilisation nominale dans les scénarios d'utilisation légère, mais si (vous) agrandissez, le bavardage pourrait commencer à poser problème. Votre pool de connexion a une limite qui peut être atteinte à un moment donné.

Je voudrais aller avec l'option 1 si vous renvoyez le même type de données entre les appels.

Cependant, il y a aussi la maintenance et la réutilisation à prendre en compte. Si vous renvoyez des données disparates (c'est-à-dire: récupérer toutes les données nécessaires pour une vue particulière), j'irais avec l'option 2 et j'optimiserais en réduisant le nombre d'appels si nécessaire.