Flux réseau d'une requête

[Wil14]

Bonjour,

Connaissez-vous le flux réseau lorsqu'on lance une requête sur un poste client ?
Mon contrôleur de domaine est distant, es-ce un élément pour avoir de mauvaises performances ?

[dbaffaleuf]

Envoyé par Wil14

Bonjour,

Connaissez-vous le flux réseau lorsqu'on lance une requête sur un poste client ?
Mon contrôleur de domaine est distant, es-ce un élément pour avoir de mauvaises performances ?

Pas évident de voir ce que tu entends par flux réseau. Lorsqu'une requête est envoyée pour exécution, l'étape d'authentification est déjà passée, donc il n'y a pas d'allers-retours vers un contrôleur de domaine. Simplement ce qui transite, ce sont les paquets TDS qui encapsulent la requête. Plus la requête est volumineuse (nb de lignes de code), plus il faudra de paquets. Mais ça ne joue pas tant que ça. Quel est ton problème exactement ? Quels sont les symptômes ?

Merci,

David B.

[Wil14]

Des temps de réponses assez long, pourtant dans le profiler les requêtes sont < 10ms.
A part le contrôleur de domaine qui est distant je ne vois pas pourquoi.

[dbaffaleuf]

Envoyé par Wil14

Des temps de réponses assez long, pourtant dans le profiler les requêtes sont < 10ms.
A part le contrôleur de domaine qui est distant je ne vois pas pourquoi.

Exécuter une requête type en local (sur la machine SQL Server) et en distant avec set statistics io on + set statistics time on:

Code :

1
2
3
SET statistics io ON
SET statistics time ON
SELECT ....

Et regarder s'il y a une différence.

[iberserk]

Petite question anodime Wil14:

Quel est le contexte de vos test? (DEBUG d'une appli .NET?)

Les développeurs ASP.NET ont ce genre de problème avec le IIS virtuel crée lors du debug de leurs appli .NET... rien de grave en soit.

[Wil14]

Bonjour,

Pas de différence en activant les compteurs.
Les conditions sont en exploitation.

Je reviens sur le trafic réseau concernant la sécurité avec mon contrôleur de domaine distant car en réalisant le test suivant :
-Connexion sur client
-Lance une requête -> ok
-Niveau administration, j’enlève les droits sur l'utilisateur
-Sur la connexion précédente toujours ouverte, je relance la même requête ->
Msg*229, Niveau*14, État*5, Ligne*1
L'autorisation SELECT a été refusée sur l'objet '...', base de données '...',...

Lors de l’exécution d'une requête il y a donc une vérification de la sécurité avec le serveur Sql.
Y a t-il également une communication avec le contrôleur de domaine lors de l'exécution d'une requête ? Si c'est le cas et que ma ligne Internet est saturée (navigation, téléchargement,...), ça pourrait être un facteur de ralentissement.

[iberserk]

Lorsqu'une requête est envoyée pour exécution, l'étape d'authentification est déjà passée, donc il n'y a pas d'allers-retours vers un contrôleur de domaine. Simplement ce qui transite, ce sont les paquets TDS qui encapsulent la requête. Plus la requête est volumineuse (nb de lignes de code), plus il faudra de paquets. Mais ça ne joue pas tant que ça. Quel est ton problème exactement ? Quels sont les symptômes ?

Il est courant que les connections soit ouvertes/fermées constamment( pas de connexion ouverte persistante côté code) donc le contrôleur de domaine est en effet sollicité à chaque connexion?

La lenteur intervient lors de l'envoie d'une requête mais je pense qu'il ne nous a pas précisé que dans ce temps était inclue une ouverture/fermeture de connexion.

Lors de l’exécution d'une requête il y a donc une vérification de la sécurité avec le serveur Sql.

En effet mais pour votre exemple, l'erreur est liée à la vérification des droits SQL et non des droits de connexion...

[Wil14]

La connexion reste ouverte après le lancement du programme.
Niveau sécurité, j'utilise un compte Sql pour cette application .Net, donc normalement indépendante d'un compte Windows avec gestion AD.
Merci pour votre aide.

[iberserk]

Des temps de réponses assez long, pourtant dans le profiler les requêtes sont < 10ms.

Ça ne veux rien dire! si vous faites 200 requêtes de 5ms pour afficher une page web vous êtes déjà à une seconde pleine sans compter le coût des aller retour réseaux.

Classique par exemple avec le LAZY loading des ORM...

[dbaffaleuf]

Envoyé par iberserk

Il est courant que les connections soit ouvertes/fermées constamment( pas de connexion ouverte persistante côté code) donc le contrôleur de domaine est en effet sollicité à chaque connexion?

Hello Bruno,

Entre l'exécution de 2 batches, oui, mais pas sur l'exécution d'un seul batch. Sur le temps d'exécution d'une seule requête, tu ne comptes pas le temps de connexion.

[mikedavem]

Je pense que le problème est ailleurs d'après ce que je vois.

En mode Web (j'ai déjà eu plusieurs fois le cas), il faut compter grosso modo le temps de la requête + + le temps de transit sur le réseau + le temps de traitement des données avec restitution de la page côté web.

Si votre requête s'effectue en moins de 10 ms il faut voir si votre problème n'est pas ailleurs.

++

[iberserk]

Entre l'exécution de 2 batches, oui, mais pas sur l'exécution d'un seul batch. Sur le temps d'exécution d'une seule requête, tu ne comptes pas le temps de connexion.

Hi David

Oui puisqu'il ne ferme pas sa connexion à chaque fois...

Je rappel qu'ici notre ami parle de

Des temps de réponses assez long

mais sans nous indiquer s'il n'y a qu'une requête... ou de multiples... en l’occurrence je ne pense pas que le problème vienne du compte de domaine...

[Wil14]

Je vous donne un peu plus de détail sur ma configuration :
Le programme tourne sur un PDA, l'application est écrite en c#.
Le PDA est en Wifi (un tracert vers le serveur sql est direct)
La connexion est ouverte lors du lancement du programme et reste active
Au niveau du profiler Sql 1 seule requête, exécutée 1 seule fois, durée<10ms

[iberserk]

C'est une appli web?

[Wil14]

Non, une application windows forms en c#