Le TCPing rapporte une latence de 20 ms entre la ferme Web et la base de données.

Conneries, les opérations de réseau sont incompétentes.

2ms, ce n'est pas rien mais c'est bien.

20 ms, c'est scandaleux. C'est un lien WAN, ou une ligne surchargée ou quelque chose comme ça.

Aucune technologie LAN dans un bâtiment ne vous donnera 20 ms, même si vous passez par une demi-douzaine de routeurs.

Je ne suis pas au courant d'une quelconque mauvaise configuration.

Le blocage de l'ICMP peut cependant avoir des effets secondaires, comme la perte de paquets TCP. La personne qui a désactivé cette fonction devrait s'informer sur TCP/IP avant de configurer des pare-feu. Selon les normes TCP, le réseau est cassé en raison de l'absence d'ICMP (qui est utilisé par exemple pour trouver la taille maximale du segment qui peut être transporté en toute sécurité).

Configuration du système d'exploitation ? J'ai déjà vu ce genre de latence lorsque le port du commutateur et la carte réseau ne s'accordaient pas sur la vitesse et le duplex. Ces paramètres sont définis dans le système d'exploitation du côté de la carte réseau. Cependant, si cela se produit, ils devraient obtenir des erreurs sur les ports de commutation en question.

C'est au niveau de SMB que la configuration du système d'exploitation entre en jeu en ce qui concerne les performances, car elle diffère selon les versions du système d'exploitation et les configurations du système d'exploitation peuvent faire en sorte que, par exemple, Windows Server 2003 et Windows Server 2008 ne fonctionnent pas bien ensemble. Cependant, cela n'est pas lié à la latence du réseau et il s'agit d'un protocole complètement différent de celui que vous utilisez pour vous connecter à SQL Server ou probablement de celui utilisé par TCPing.

C'est dans le matériel, soit le matériel lui-même est insuffisant ou mal configuré. C'est la couche un ou deux, ou le jeu de règles du pare-feu, bonne chance avec eux.

Lorsque vous tcping SQL à partir d'un serveur IIS, capturez le trafic en utilisant wireshark installé sur SQL. Capturez tout ce que vous voulez puis éclaircissez-le avec le filtre d'affichage. ou vous pouvez faire un filtre de capture comme : TCP port 1433 et faire un clic droit sur un paquet et faire follow TCP stream...

Demandez à vos administrateurs FW d'examiner cette question : http://support.microsoft.com/kb/968872

Il n'y a pas que le 1433 à ouvrir et il semble qu'ils ne soient pas très bons dans ce domaine, auquel cas leur jeu de règles est suspect, l'entrée icmp de la DMZ devrait être bloquée. Il ne devrait pas être utilisé. à l'intérieur d'un noyau où se trouvent votre station de travail et SQL est très bien. Je suppose que votre réseau est logiquement composé de deux couches, une publique où se trouve votre IIS et une centrale où se trouve SQL.

Par segment, ils veulent dire sous-réseau ou vlan ? S'il s'agit d'un VLAN, il y a des règles pour cela.... vous pouvez avoir le "segment" ouvert au TCP 1433, et non à l'UDP ou vous avez un vlan dans lequel un hôte manque ou n'est pas présent alors qu'il devrait l'être, au lieu de cela il est dans un autre.

Avez-vous configuré le système d'exploitation pour qu'il n'utilise pas le service de navigation de l'ordinateur, WINS, etc. afin qu'il n'essaie pas d'identifier votre SQL par netbios ? Cela pourrait ralentir les choses.

Je voudrais ouvrir une capture wireshark sur votre boîte SQL et voir ce que vous voyez. Vous pouvez désactiver le défilement automatique des paquets dans la capture en direct afin qu'ils ne passent pas en criant. Laissez la capture faire quelques transactions, puis arrêtez-la et utilisez le filtre d'affichage afin de forer vers le bas, faites comme tpc.port eq 1433 je pense. Le filtre de capture serait : port 1433 et cela obtient tous les protocoles uniquement destinés à et depuis le 1433 sur le sous-réseau dont cette machine est membre.

Vous verrez probablement beaucoup de retransmissions, d'entrées en double et de choses de cette nature. Regardez ARP, voyez si tout va bien, si vous voyez du trafic netbios, faites ce que vous avez à faire pour le désactiver dans le système d'exploitation. Par exemple, sur IIS, si vous avez décoché Windows Client ou le partage de fichiers dans la pile réseau, je ne me souviens plus exactement. Vous voulez seulement TCP et UDP entre sql et IIS. Pas de NetBT, NetBios ou autre. TOUS les DNS, pas de WINS, etc... Bonne chance avec votre équipe réseau.

J'essaierais de désactiver le déchargement de la cheminée tcp. http://www.iislogs.com/steveschofield/troubleshooting-iis-7-network-performance-issues-and-tcp-chimney-offload-receive-side-scaling-and-network-direct-memory-access