Problème suivante à un changement de Route sur le réseau
2 réponses
Romelard Fabrice [MVP]
Bonjour,
Je pose cette question ici, car je ne trouve pas de réponse du tout.
Actuellement, suite à des problèmes de preformances pour une application
importante (WEB+Base), celle-ci a été migrée totalement sur une nouvelle
machine qui lui est dédiée (SQL Server 2000 SP3 - Windows 2000 SP4).
L'application est développée sous Framework.NET 1.0. Celle-ci fonctionne
très bien depuis cette migratoin (les accès sur la base étant locaux).
A la suite de cette migration, pour encore améliorer les temps de réponse
d'un centre distant (Strasbourg alors que nous sommes en RP), les routes des
routeurs ont été modifiées pour les accès venant de Strasbourg. Ainsi pour
les accès à l'application WEB, ca a fonctionné correctement et les routes
sembles correctes.
On arrive maintenant au noeud du problème. Depuis ce changement les
requettes SQL venant d'autres machines sont extrements longues sauf pour les
requettes locales ou les requettes venant de strasbourg.
Voila un petit exemple de test fait avec un Query Analyser sur une table de
137 000 lignes env : (select *)
----------------------------------------------------------------------------
----
Machine Bases de données
Requette à partir de
Ancien Nouveau
Localhost
10 a 15 s 10 à 15 s
Machine cliente 20
à 30 s plus de 2 min 30 s
Serveur sur le même sous réseau env 30 s
plus de 2 min 30 s
Serveur de la DMZ env 30
s plus de 3 min
Serveur de Strasbourg env 1
min env 1 min
----------------------------------------------------------------------------
----
Les tracroutes entre les machines sont corrects à chaque fois.
Notre question serait :
- SQL Server conserverait-il en cache les routes ?
- Comment pouvoir suivre le trajet du flux SQL ?
- Quelqu'un a-t'il une idée sur le problème ?
Dans l'attente d'une réponse, merci d'avance.
--
Romelard Fabrice (Alias F___)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bonjour,
Je ne pense pas pour ma part que sql server garde en cache les routes.
Pour sui vre le trajet on peut peut être utiliser le moniteur réseau par exemple
Concernant l'idée j'en ai une a soumettre mais qui peut être extrêmement stupide cela dit qui ne tente rien
Voilà l'idée si dans le site web la connection sur la base sql server fait référence à l'adresse ip du serveur imaginons que la chaine de connection n'ai pas été modifié pour aller taper sur le bon port en fait elle utilise peut être le port du site web ou un ancien port topo strasbourg arrive sur le bon port directement ou la bonne partie du réseau et pas les autres machine si en local cela tourne bien c parce qu'il ne parcourt pas le réseau a la recherche du serveur si strabourg utilise déjà de suite les bonnes routes et marche bien alors c que les postes en local ne sont pas sur les bonnes routes où "n'arrive pas du bon coté" et perdent du temps à chercher le serveur sqlserveur un masque de sous réseau, une adresse ip, un port de communication mal paramétré peut être sur le site web en tout cas la partie d'application qui vient se connecter sur la base ou encore le IIS par exemple si les session sont stocké dans sql serveur et ceux sont les sessions qui ralentissent tout pour ma part je chercherais plutot dans cette direction une mauvaise route a un endroit les fichier web.,config, machine.config chose comme ça
Je sais c idiot comme idée mais ça me parait assez probable lol
Sebastien
"Romelard Fabrice [MVP]" a écrit dans le message de news:40c06e0d$0$4253$
Bonjour,
Je pose cette question ici, car je ne trouve pas de réponse du tout. Actuellement, suite à des problèmes de preformances pour une application importante (WEB+Base), celle-ci a été migrée totalement sur une nouvelle machine qui lui est dédiée (SQL Server 2000 SP3 - Windows 2000 SP4).
L'application est développée sous Framework.NET 1.0. Celle-ci fonctionne très bien depuis cette migratoin (les accès sur la base étant locaux).
A la suite de cette migration, pour encore améliorer les temps de réponse d'un centre distant (Strasbourg alors que nous sommes en RP), les routes
des
routeurs ont été modifiées pour les accès venant de Strasbourg. Ainsi pour les accès à l'application WEB, ca a fonctionné correctement et les routes sembles correctes.
On arrive maintenant au noeud du problème. Depuis ce changement les requettes SQL venant d'autres machines sont extrements longues sauf pour
les
requettes locales ou les requettes venant de strasbourg. Voila un petit exemple de test fait avec un Query Analyser sur une table
Machine Bases de données Requette à partir de Ancien Nouveau
Localhost 10 a 15 s 10 à 15 s Machine cliente
20
à 30 s plus de 2 min 30 s Serveur sur le même sous réseau env 30 s plus de 2 min 30 s Serveur de la DMZ env
30
s plus de 3 min Serveur de Strasbourg env 1 min env 1 min --------------------------------------------------------------------------
--
----
Les tracroutes entre les machines sont corrects à chaque fois.
Notre question serait : - SQL Server conserverait-il en cache les routes ? - Comment pouvoir suivre le trajet du flux SQL ? - Quelqu'un a-t'il une idée sur le problème ?
Dans l'attente d'une réponse, merci d'avance. -- Romelard Fabrice (Alias F___)
Bonjour,
Je ne pense pas pour ma part que sql server garde en cache les routes.
Pour sui vre le trajet on peut peut être utiliser le moniteur réseau par
exemple
Concernant l'idée j'en ai une a soumettre mais qui peut être extrêmement
stupide cela dit qui ne tente rien
Voilà l'idée si dans le site web la connection sur la base sql server fait
référence à l'adresse ip du serveur imaginons que la chaine de connection
n'ai pas été modifié pour aller taper sur le bon port en fait elle utilise
peut être le port du site web ou un ancien port topo strasbourg arrive sur
le bon port directement ou la bonne partie du réseau et pas les autres
machine si en local cela tourne bien c parce qu'il ne parcourt pas le réseau
a la recherche du serveur si strabourg utilise déjà de suite les bonnes
routes et marche bien alors c que les postes en local ne sont pas sur les
bonnes routes où "n'arrive pas du bon coté" et perdent du temps à chercher
le serveur sqlserveur un masque de sous réseau, une adresse ip, un port de
communication mal paramétré peut être sur le site web en tout cas la partie
d'application qui vient se connecter sur la base ou encore le IIS par
exemple si les session sont stocké dans sql serveur et ceux sont les
sessions qui ralentissent tout pour ma part je chercherais plutot dans cette
direction une mauvaise route a un endroit les fichier web.,config,
machine.config chose comme ça
Je sais c idiot comme idée mais ça me parait assez probable lol
Sebastien
"Romelard Fabrice [MVP]" <fabrice_69@hotmail.com> a écrit dans le message de
news:40c06e0d$0$4253$626a14ce@news.free.fr...
Bonjour,
Je pose cette question ici, car je ne trouve pas de réponse du tout.
Actuellement, suite à des problèmes de preformances pour une application
importante (WEB+Base), celle-ci a été migrée totalement sur une nouvelle
machine qui lui est dédiée (SQL Server 2000 SP3 - Windows 2000 SP4).
L'application est développée sous Framework.NET 1.0. Celle-ci fonctionne
très bien depuis cette migratoin (les accès sur la base étant locaux).
A la suite de cette migration, pour encore améliorer les temps de réponse
d'un centre distant (Strasbourg alors que nous sommes en RP), les routes
des
routeurs ont été modifiées pour les accès venant de Strasbourg. Ainsi pour
les accès à l'application WEB, ca a fonctionné correctement et les routes
sembles correctes.
On arrive maintenant au noeud du problème. Depuis ce changement les
requettes SQL venant d'autres machines sont extrements longues sauf pour
les
requettes locales ou les requettes venant de strasbourg.
Voila un petit exemple de test fait avec un Query Analyser sur une table
Machine Bases de données
Requette à partir de
Ancien Nouveau
Localhost
10 a 15 s 10 à 15 s
Machine cliente
20
à 30 s plus de 2 min 30 s
Serveur sur le même sous réseau env 30 s
plus de 2 min 30 s
Serveur de la DMZ env
30
s plus de 3 min
Serveur de Strasbourg env 1
min env 1 min
--------------------------------------------------------------------------
--
----
Les tracroutes entre les machines sont corrects à chaque fois.
Notre question serait :
- SQL Server conserverait-il en cache les routes ?
- Comment pouvoir suivre le trajet du flux SQL ?
- Quelqu'un a-t'il une idée sur le problème ?
Dans l'attente d'une réponse, merci d'avance.
--
Romelard Fabrice (Alias F___)
Je ne pense pas pour ma part que sql server garde en cache les routes.
Pour sui vre le trajet on peut peut être utiliser le moniteur réseau par exemple
Concernant l'idée j'en ai une a soumettre mais qui peut être extrêmement stupide cela dit qui ne tente rien
Voilà l'idée si dans le site web la connection sur la base sql server fait référence à l'adresse ip du serveur imaginons que la chaine de connection n'ai pas été modifié pour aller taper sur le bon port en fait elle utilise peut être le port du site web ou un ancien port topo strasbourg arrive sur le bon port directement ou la bonne partie du réseau et pas les autres machine si en local cela tourne bien c parce qu'il ne parcourt pas le réseau a la recherche du serveur si strabourg utilise déjà de suite les bonnes routes et marche bien alors c que les postes en local ne sont pas sur les bonnes routes où "n'arrive pas du bon coté" et perdent du temps à chercher le serveur sqlserveur un masque de sous réseau, une adresse ip, un port de communication mal paramétré peut être sur le site web en tout cas la partie d'application qui vient se connecter sur la base ou encore le IIS par exemple si les session sont stocké dans sql serveur et ceux sont les sessions qui ralentissent tout pour ma part je chercherais plutot dans cette direction une mauvaise route a un endroit les fichier web.,config, machine.config chose comme ça
Je sais c idiot comme idée mais ça me parait assez probable lol
Sebastien
"Romelard Fabrice [MVP]" a écrit dans le message de news:40c06e0d$0$4253$
Bonjour,
Je pose cette question ici, car je ne trouve pas de réponse du tout. Actuellement, suite à des problèmes de preformances pour une application importante (WEB+Base), celle-ci a été migrée totalement sur une nouvelle machine qui lui est dédiée (SQL Server 2000 SP3 - Windows 2000 SP4).
L'application est développée sous Framework.NET 1.0. Celle-ci fonctionne très bien depuis cette migratoin (les accès sur la base étant locaux).
A la suite de cette migration, pour encore améliorer les temps de réponse d'un centre distant (Strasbourg alors que nous sommes en RP), les routes
des
routeurs ont été modifiées pour les accès venant de Strasbourg. Ainsi pour les accès à l'application WEB, ca a fonctionné correctement et les routes sembles correctes.
On arrive maintenant au noeud du problème. Depuis ce changement les requettes SQL venant d'autres machines sont extrements longues sauf pour
les
requettes locales ou les requettes venant de strasbourg. Voila un petit exemple de test fait avec un Query Analyser sur une table
Machine Bases de données Requette à partir de Ancien Nouveau
Localhost 10 a 15 s 10 à 15 s Machine cliente
20
à 30 s plus de 2 min 30 s Serveur sur le même sous réseau env 30 s plus de 2 min 30 s Serveur de la DMZ env
30
s plus de 3 min Serveur de Strasbourg env 1 min env 1 min --------------------------------------------------------------------------
--
----
Les tracroutes entre les machines sont corrects à chaque fois.
Notre question serait : - SQL Server conserverait-il en cache les routes ? - Comment pouvoir suivre le trajet du flux SQL ? - Quelqu'un a-t'il une idée sur le problème ?
Dans l'attente d'une réponse, merci d'avance. -- Romelard Fabrice (Alias F___)
Gurvann
Bonjour,
C'est un pbl de carte RZO ( utilisation de NETMON)
Gurvann "Romelard Fabrice [MVP]" a écrit dans le message de news:40c06e0d$0$4253$
Bonjour,
Je pose cette question ici, car je ne trouve pas de réponse du tout. Actuellement, suite à des problèmes de preformances pour une application importante (WEB+Base), celle-ci a été migrée totalement sur une nouvelle machine qui lui est dédiée (SQL Server 2000 SP3 - Windows 2000 SP4).
L'application est développée sous Framework.NET 1.0. Celle-ci fonctionne très bien depuis cette migratoin (les accès sur la base étant locaux).
A la suite de cette migration, pour encore améliorer les temps de réponse d'un centre distant (Strasbourg alors que nous sommes en RP), les routes
des
routeurs ont été modifiées pour les accès venant de Strasbourg. Ainsi pour les accès à l'application WEB, ca a fonctionné correctement et les routes sembles correctes.
On arrive maintenant au noeud du problème. Depuis ce changement les requettes SQL venant d'autres machines sont extrements longues sauf pour
les
requettes locales ou les requettes venant de strasbourg. Voila un petit exemple de test fait avec un Query Analyser sur une table
Machine Bases de données Requette à partir de Ancien Nouveau
Localhost 10 a 15 s 10 à 15 s Machine cliente
20
à 30 s plus de 2 min 30 s Serveur sur le même sous réseau env 30 s plus de 2 min 30 s Serveur de la DMZ env
30
s plus de 3 min Serveur de Strasbourg env 1 min env 1 min --------------------------------------------------------------------------
--
----
Les tracroutes entre les machines sont corrects à chaque fois.
Notre question serait : - SQL Server conserverait-il en cache les routes ? - Comment pouvoir suivre le trajet du flux SQL ? - Quelqu'un a-t'il une idée sur le problème ?
Dans l'attente d'une réponse, merci d'avance. -- Romelard Fabrice (Alias F___)
Bonjour,
C'est un pbl de carte RZO ( utilisation de NETMON)
Gurvann
"Romelard Fabrice [MVP]" <fabrice_69@hotmail.com> a écrit dans le message de
news:40c06e0d$0$4253$626a14ce@news.free.fr...
Bonjour,
Je pose cette question ici, car je ne trouve pas de réponse du tout.
Actuellement, suite à des problèmes de preformances pour une application
importante (WEB+Base), celle-ci a été migrée totalement sur une nouvelle
machine qui lui est dédiée (SQL Server 2000 SP3 - Windows 2000 SP4).
L'application est développée sous Framework.NET 1.0. Celle-ci fonctionne
très bien depuis cette migratoin (les accès sur la base étant locaux).
A la suite de cette migration, pour encore améliorer les temps de réponse
d'un centre distant (Strasbourg alors que nous sommes en RP), les routes
des
routeurs ont été modifiées pour les accès venant de Strasbourg. Ainsi pour
les accès à l'application WEB, ca a fonctionné correctement et les routes
sembles correctes.
On arrive maintenant au noeud du problème. Depuis ce changement les
requettes SQL venant d'autres machines sont extrements longues sauf pour
les
requettes locales ou les requettes venant de strasbourg.
Voila un petit exemple de test fait avec un Query Analyser sur une table
Machine Bases de données
Requette à partir de
Ancien Nouveau
Localhost
10 a 15 s 10 à 15 s
Machine cliente
20
à 30 s plus de 2 min 30 s
Serveur sur le même sous réseau env 30 s
plus de 2 min 30 s
Serveur de la DMZ env
30
s plus de 3 min
Serveur de Strasbourg env 1
min env 1 min
--------------------------------------------------------------------------
--
----
Les tracroutes entre les machines sont corrects à chaque fois.
Notre question serait :
- SQL Server conserverait-il en cache les routes ?
- Comment pouvoir suivre le trajet du flux SQL ?
- Quelqu'un a-t'il une idée sur le problème ?
Dans l'attente d'une réponse, merci d'avance.
--
Romelard Fabrice (Alias F___)
C'est un pbl de carte RZO ( utilisation de NETMON)
Gurvann "Romelard Fabrice [MVP]" a écrit dans le message de news:40c06e0d$0$4253$
Bonjour,
Je pose cette question ici, car je ne trouve pas de réponse du tout. Actuellement, suite à des problèmes de preformances pour une application importante (WEB+Base), celle-ci a été migrée totalement sur une nouvelle machine qui lui est dédiée (SQL Server 2000 SP3 - Windows 2000 SP4).
L'application est développée sous Framework.NET 1.0. Celle-ci fonctionne très bien depuis cette migratoin (les accès sur la base étant locaux).
A la suite de cette migration, pour encore améliorer les temps de réponse d'un centre distant (Strasbourg alors que nous sommes en RP), les routes
des
routeurs ont été modifiées pour les accès venant de Strasbourg. Ainsi pour les accès à l'application WEB, ca a fonctionné correctement et les routes sembles correctes.
On arrive maintenant au noeud du problème. Depuis ce changement les requettes SQL venant d'autres machines sont extrements longues sauf pour
les
requettes locales ou les requettes venant de strasbourg. Voila un petit exemple de test fait avec un Query Analyser sur une table
Machine Bases de données Requette à partir de Ancien Nouveau
Localhost 10 a 15 s 10 à 15 s Machine cliente
20
à 30 s plus de 2 min 30 s Serveur sur le même sous réseau env 30 s plus de 2 min 30 s Serveur de la DMZ env
30
s plus de 3 min Serveur de Strasbourg env 1 min env 1 min --------------------------------------------------------------------------
--
----
Les tracroutes entre les machines sont corrects à chaque fois.
Notre question serait : - SQL Server conserverait-il en cache les routes ? - Comment pouvoir suivre le trajet du flux SQL ? - Quelqu'un a-t'il une idée sur le problème ?
Dans l'attente d'une réponse, merci d'avance. -- Romelard Fabrice (Alias F___)
