Salut,
 
Certains ici ont-ils deja eu l'occasion de faire du tuning de stack TCP/IP sur des serveurs Win2000 ?
 
Je cherche en particulier un feedback sur le settings TcpDelAckTicks mis a 0. Je ne suis personnellement pas convaincu de l'utilite de mettre ce setting a 0, mais un collegue semble y croire.
 
On constate bien le changement de comportement attendu lorsqu'on passe ce parametre de sa valeur par defaut (2) a 0. Mais en terme de performance globale, je n'ai pour l'instant mesure aucune difference.
 
Des avis ou temoignages a ce sujet ?
Merci.

http://support.microsoft.com/defau [...] ;fr;321169
 

Merci pour ce lien tres interessant
 
Mais dans le cas decrit dans ce lien, il est logique que ce parametre mis a 0 ameliore l'echange car:
 

 
Mais dans le cas de mon serveur (HTTP - IIS 5.0), je n'ai pas pu mesurer de difference.
 
J'espere finir par tomber sur un article confirmant ou infirmant cette assertion.

D'après l'article on améliore les perfs du serveur mais augmente la latence du réseau du fait des accusés.

D'accord avec toi, mais attention: l'article ne parle que du protocole SMB entre un type de client donne et un serveur donne, et du fait du traitement synchrone du redirecteur. Ce qui explique effectivement qu'un accuse de reception envoye immediatement ameliore la performance globale.
 
Mais je ne suis pas sur que cela soit le cas sur d'autres protocoles comme HTTP par exemple.

Tt à fait c'est bien dans le cas d'un controleur de domaine.
Tu as lu cette article il en parle :
http://forum.hardware.fr/hardwaref [...] 2103-1.htm

Je viens de lire l'article. Merci pour la reference.
 
La plupart du temps, ce genre d'article s'attarde sur l'optimisation du cote "client" pour optimiser l'utilisation des ressources internet (download par exemple).
 
Dans mon cas, la question se pose cote serveur. Je vais tacher d'etre plus clair. Imaginons le scenario simple suivant, d'une requete HTTP, vu au niveau TCP
 
1. Client --> [SYN] --> Server
2. Client <-- [SYN|ACK] <-- Server
3. Client --> [ACK] --> Server
 
Jusque la, triple handshake TCP classique. Ensuite:
 
4. Client --> GET /index.html [PSH|ACK] --> Server
5. Client <-- [ACK] <-- Server
6. Client <-- HTTP1/0 200 OK [ACK] <-- Server
 
Puis fin de la connexion, je passe les details.
 
Toute ma question repose sur l'etape 5:
CAS 1: Quand je mets le TcpDelAckTicks a 0, cet ACK du server est immediat, juste apres le GET du client. Les donnees en elles meme (le fichier index.html) arrivent quelques ms apres.
CAS 2: Quand je mets le TcpDelAckTicks a 2 (valeur par defaut), les etapes 5 et 6 n'en font plus qu'une, c'est a dire que le serveur va avoir le temps d'ACKnowledger la requete tout en lui renvoyant les donnees.
 
Pour moi, il n'y a pas eu optimisation a envoyer un ACK de maniere immmediate apres le GET (CAS 1), le temps de reponse global pour la requete, vu du client, n'est en rien ameliore.
 
La question qui se trouve derriere est la suivante:
Les donnees de l'etape 4 (le GET) sont-elles traitees par la couche applicative (le serveur web) immediatement a la reception, ou la stack IP ne remonte-t-elle ces donnees a la couche applicative qu'une fois qu'elle les a ACKnowledger (auquel cas il y a potentiellement un delai de 200ms) ?
 
Tout ca est assez technique, mais tres interessant.

 
m'interesse de le savoir aussi

En y reflechissant, je crois que la reponse est dans question :
 
Dans le CAS 2 decrit (qui est la valeur par defaut: TcpDelAckTicks = 2), on voir clairement que le serveur traite la requete du client avant meme d'avoir fait un acknowledge puisqu'il envoit le debut de la reponse dans le meme packet que son premier ACK.
 
CQFD.
 
En utilisant un network sniffer on voit tres bien qu'a part charger le reseau inutilement, le serveur ne repondra pas plus vite au client en renvoyant le premier ACK immediatement apres la premiere requete.

cool

Tout a fait c bien ce qu'il disait (la docs Kro pr la partie SMB) çà fait un engouffrement du réseau.