IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C# Discussion :

Temp de reponse


Sujet :

C#

  1. #1
    Membre averti
    Inscrit en
    Août 2009
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Août 2009
    Messages : 12
    Par défaut Temp de reponse
    Bonjour ,

    Une présentation rapide de mon problème.

    1 procedure stockée de type select sur sqlserver 2005.
    1 dataset avec methode FILL utilisant cette procedure. ( Visual Studio 2008).

    Si j'execute ma procédure en mode commande sql le temp de reponse moyen est de 1 à 2 secondes.

    Par contre quand j'utilise le fill ce mon dataset alors j'ai des temps de reponse supérieur 5 à 8 secondes et meme des timeout ( delai depassé).

    En attendant vos propositions de recherches ou de solutions peut être...

    A bientot

  2. #2
    Expert éminent Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 197
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 197
    Par défaut
    ne pas utiliser de dataset, c'est pour les débutants ^^
    sans, tu pourras tomber à environ 3 secondes je pense (pas encore ausi rapide que directement sous sql server)
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  3. #3
    Membre averti
    Inscrit en
    Août 2009
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Août 2009
    Messages : 12
    Par défaut
    Pour un debutant as tu un exemple de code... Thanks

  4. #4
    Expert éminent Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 197
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 197
    Par défaut
    bah un fois que tu as ton sqlcommand, tu obtiens le sqldatareader avec .ExecuteReader et tu charges les données toi meme dans des collections de classes
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  5. #5
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Par défaut
    Postuler que c'est a priori l'utilisation du DataSet qui entraine une telle différence de temps de réponse me semble un peu excessif.

    Même si le fill d'un DataSet est en efffet moins rapide que la lecture via un DataReader par exemple, son mode déconnecté est parfois incontournable - si une autre commande doit être exécutée pendant l'examen des données lues par exemple - , donc rejeter son utilisation a priori sans connaître le contexte me semble relever un peu de l'article de foi.

    Combien ta requête retourne de lignes ?

    Poste plutôt ton code qui interroge la base. (à condition qu'il soit bien entendu que quand tu parles de temps d'exécution comparée entre SMSS et ton appli, tu te limites uniquement à l'accès données et que tu n'inclus pas un éventuel traitement ou affichage derrière, auquel cas, il s'agirait d'une comparaison choux vs navets qui n'aurait aucun interêt).

  6. #6
    Expert éminent Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 197
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 197
    Par défaut
    le dataset est 3x plus à remplir qu'une utilisation du datareader donc il me semble logique de "postuler" ca

    de plus le mode "déconnecté" du dataset si j'ai bien suivi le code c'est qu'au moment d'un update, il fait d'abord une requete pour vérifier que la ligne a toujours la valeur qu'il avait lu au départ, donc on peut reproduire la meme chose
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  7. #7
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    le dataset est 3x plus à remplir qu'une utilisation du datareader donc il me semble logique de "postuler" ca
    Affirmation exagérée.

    Je viens de faire un test sur une table de taille moyenne (110000 lignes, une trentaine de colonne) et j'obtiens :

    Temps Lecture datareader 21072,61 ms
    Temps Lecture dataSet 23480,015 ms
    sur une table de plus petite taille (10 colonnes, 75000 lignes) , j'obtiens

    Temps Lecture datareader 844,1766 ms
    Temps Lecture dataSet 859,8095 ms
    On est très loin des "X3" que tu affirmes péremptoirement. Cela peut peut être arriver, sur une grosse table.

    voici le code que j'ai utilisé :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
     
    private static void comparePerf()
    {
    string connectionString = @"Application Name=TestPerf;Server=XXXXX\SQL2005;Database=XXXX;Trusted_Connection=True;";
    string sql = "select * from XXXXXXX";
    DateTime a = DateTime.Now;
    using (SqlConnection connection = new SqlConnection(connectionString))
    {
    connection.Open();
    using (SqlCommand command = connection.CreateCommand())
    {
    command.CommandText = sql;
    int readerLineCount = 0;
    using (SqlDataReader reader = command.ExecuteReader())
    {
    while (reader.Read())
    {
    object[] values = new object[reader.FieldCount];
    for (int i = 0; i < reader.FieldCount; i++)
    {
    values[i] = reader[i];
    }
    readerLineCount++;
    }
    reader.Close();
    }
    }
    connection.Close();
    }
    DateTime b = DateTime.Now;
    DataSet dataSet = new DataSet();
    using (SqlConnection connection = new SqlConnection(connectionString))
    {
    connection.Open();
    using (SqlCommand command = connection.CreateCommand())
    {
    command.CommandText = sql;
    SqlDataAdapter adapter = new SqlDataAdapter(command);
     
    adapter.Fill(dataSet);
    }
    connection.Close();
    }
    DateTime c = DateTime.Now;
    StringBuilder sb = new StringBuilder();
    sb.AppendFormat("Temps Lecture datareader {0} ms", (b - a).TotalMilliseconds);
    sb.AppendLine();
    sb.AppendFormat("Temps Lecture dataSet {0} ms", (c - b).TotalMilliseconds);
    sb.AppendLine();
    Console.WriteLine(sb);
    Console.ReadKey();
    }
    de plus le mode "déconnecté" du dataset si j'ai bien suivi le code c'est qu'au moment d'un update, il fait d'abord une requete pour vérifier que la ligne a toujours la valeur qu'il avait lu au départ, donc on peut reproduire la meme chose
    Il n'a à aucun moment parler de mettre à jour ses données. Personnellement, je n'utilise pas les Dataset si j'ai des mises à jour à effectuer.

  8. #8
    Expert éminent Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 197
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 197
    Par défaut
    je persiste ^^ le reader dans mon test est presque 2x plus rapide (1680ms ds, 920 reader ; 50k lignes et à vue de nez 60 colonnes)

    sauf que j'utilise le reader.getvalues ; il me semble de mémoire que le code de la propriété item comparé au code de getvalues fait apparaitre facilement qu'il y a un gain de temps à trouver

    Citation Envoyé par Bluedeep Voir le message
    je n'utilise pas les Dataset si j'ai des mises à jour à effectuer.
    quel est l'interet alors ? (je n'ai jamais vraiment utilisé de dataset ...)
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  9. #9
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    quel est l'interet alors ? (je n'ai jamais vraiment utilisé de dataset ...)
    Comme déjà dit, le problème avec le DataReader est que tu ne peux pas exécuter une autre commande sur la connexion quand il est ouvert.

    Donc si tu dois faire quelque chose ne permettant pas d'utiliser une requête "ensembliste" (traitement métier pendant l'examen des lignes/colonnes nécessitant une autre requête non prédictive avant l'examen des données ou nécessitant un appel sur des données en cache, etc, etc ....), c'est souvent la meilleure solution. (ou utiliser deux connexions pour le traitement).

  10. #10
    Membre émérite
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2007
    Messages
    693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Juillet 2007
    Messages : 693
    Par défaut
    Comme déjà dit, le problème avec le DataReader est que tu ne peux pas exécuter une autre commande sur la connexion quand il est ouvert.
    Euh techniquement tu vas également avoir un problème pour exécuter une autre requête durant le Fill du DataSet.

    Pour revenir au sujet, outre les différences DataSet/DataReader, il y a aussi une autre possibilité d'optim, c'est sur la requête ! Moi j'aimerai bien avoir plus d'info dessus !

  11. #11
    Expert éminent Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 197
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 197
    Par défaut
    Citation Envoyé par ostenhard Voir le message
    Euh techniquement tu vas également avoir un problème pour exécuter une autre requête durant le Fill du DataSet.
    +1
    le fill utilise un datareader de toute façon ^^ (étant le seul objet pour rapatrier des données, linq et autres EF utilisent aussi un datareader à mon avis)
    et puis avoir plusieurs connexions c'est pas contraignant sur un vrai sgbdr

    Citation Envoyé par ostenhard Voir le message
    Pour revenir au sujet, outre les différences DataSet/DataReader, il y a aussi une autre possibilité d'optim, c'est sur la requête ! Moi j'aimerai bien avoir plus d'info dessus !
    pour optimiser le temps d'exécution d'une requete il faut comprendre le fonctionnement du sgbdr pour en optimiser le schéma surtout (et quelques indexes)
    ensuite éviter les tables temporaires, les jointures sont souvent plus rapide que les in/not in, une jointure est beaucoup plus rapide que de faire référence à un champ d'une requete dans une sous requete...
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  12. #12
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Par défaut
    Citation Envoyé par ostenhard Voir le message
    Euh techniquement tu vas également avoir un problème pour exécuter une autre requête durant le Fill du DataSet.
    Je n'ai jamais parlé d'exécuter une requête pendant le fill du dataset. Simplement, après le Fill, je dispose des données en mode déconnecté et peu itérer sur les lignes tout en émettant d'autre commandes,chose qui est impossible avec un reader, sauf à utiliser une autre connexion.

    Pour revenir au sujet, outre les différences DataSet/DataReader, il y a aussi une autre possibilité d'optim, c'est sur la requête ! Moi j'aimerai bien avoir plus d'info dessus !
    Tout à fait; et dans ce cas, le choix du mode de récupération des données n'a aucun impact sur le temps d'exécution de la requête.

  13. #13
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    je persiste ^^ le reader dans mon test est presque 2x plus rapide (1680ms ds, 920 reader ; 50k lignes et à vue de nez 60 colonnes)
    Je ne comprends pas que tu puisses arriver à ce résultat, sauf,peut être, à utiliser un serveur local. (et encore).

    sauf que j'utilise le reader.getvalues ; il me semble de mémoire que le code de la propriété item comparé au code de getvalues fait apparaitre facilement qu'il y a un gain de temps à trouver
    Je viens de modifier le code de test pour utiliser le getvalues et il n'y a aucun gain significatif. (après essais multiple pour lisser les variatiions engendrées par les charges transitoires réseau). Pour être précis u léger gain sur la "petite" table et une légere perte sur la "moyenne" (où le reader devient d'ailleurs plus lent que le DataSet).

  14. #14
    Expert éminent Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 197
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 197
    Par défaut
    Citation Envoyé par Bluedeep Voir le message
    Je n'ai jamais parlé d'exécuter une requête pendant le fill du dataset. Simplement, après le Fill, je dispose des données en mode déconnecté et peu itérer sur les lignes tout en émettant d'autre commandes,chose qui est impossible avec un reader, sauf à utiliser une autre connexion.
    !?
    avec un reader aussi, tu mets tes données en ram et puis tu peux faire d'autre requete après le close du reader sans fermer la connexion ...

    pour mes tests en effet je suis sur un serveur local, je ne sais plus si mes anciens tests l'étaient aussi
    tu as bien testé après plusieurs exécutions (cause jit et cache du sgbdr) ?
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  15. #15
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    !?
    avec un reader aussi, tu mets tes données en ram et puis tu peux faire d'autre requete après le close du reader sans fermer la connexion ...
    Tout à fait, mais dans ce cas tu utilises ton reader pour itérer sur tes lignes, puis tu itéres à nouveau sur la/les listes; tu le fais avec moins de lignes de code avec le DataSet.

    pour mes tests en effet je suis sur un serveur local, je ne sais plus si mes anciens tests l'étaient aussi
    Ceci explique peut être cela.

    tu as bien testé après plusieurs exécutions (cause jit et cache du sgbdr) ?
    Bien sur, comme mentionné :

    après essais multiple pour lisser les variatiions engendrées par les charges transitoires réseau

Discussions similaires

  1. [XPath] meilleur API au niveau du temps de reponse
    Par Mouss99 dans le forum XML/XSL et SOAP
    Réponses: 1
    Dernier message: 05/09/2006, 17h58
  2. Temps de reponse
    Par Plumet dans le forum Oracle
    Réponses: 12
    Dernier message: 11/05/2006, 16h14
  3. temps de reponse d'une requetes ?
    Par Melvine dans le forum Oracle
    Réponses: 1
    Dernier message: 27/03/2006, 16h54
  4. Réponses: 4
    Dernier message: 13/03/2006, 17h46
  5. ameliorer le temps de reponse
    Par subzero82 dans le forum MS SQL Server
    Réponses: 7
    Dernier message: 22/08/2005, 12h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo