Bonjour,

Je dispose d'un server apache hébergé sur un windows 2008 r2. J'ai un problème de débit lors des téléchargement de fichiers environ 300kb/sec. Apres pas mal de recherche j'ai remarquer que sur plusieurs forum, les personnes évoquent qu'il n'y a pas de bridage par default. Mais il y a quelque chose que je n'arrive pas à comprendre. Lorsque je crée un server apache sur linux par défaut le débit est triplé. La Configuration des deux server windows et linux sont par défaut. je passe de 300kb/sec à 1mb/sec.

Lors d'un test en local le débit est de 20mb/sec sur les deux. (ce qui n'est pas beaucoup non plus pour une connexion gigabit entre les servers)

Quelqu'un aurait-il une explication ?

Bonjour,

Il faudrait plus d'information sur le setup.
Les serveurs testés sont sur le même réseau local, c'est ça ? Pour ton test distant, derrière quel type de connexion fais-tu le test ?
Et enfin, vois-tu le même problème avec d'autres logiciels (IIS par exemple) ? Avec d'autres protocoles (FTP par exemple) ?

Cordialement.

Bonjour,

Oui les serveurs sont sur le même réseau, les tests ont été effectués par plusieurs connexion adsl différente. Je n'est pas fait le test sur un server IIS. Il n'y a pas de problème concernant l'utilisation de protocole FTP le débit reste normal. J'ai réalisé deux installation par défaut, une windows 7 et une sur windows 2008 r2 . (apache2.2.22) et un autre avec (apache 2.2.22 openssl 0.9.8t)

A chaque fois les test des différentes connexion adsl montrent que le débit est divisé par 3 par rapport à un serveur linux debian.

Bonsoir,

Je vais peut être paraître lourd avec mes questions mais pour le moment il n'y a pas assez de détails pour émettre une quelconque explication.

Comment les serveurs sont-ils connectés à internet. Par une connexion ADSL également ?
On aurait ceci :
Serveurs <----- Connexion ADSL? ------> Internet <------ Connexion ADSL ------> Client
Quel sont les débits montant et descendant respectifs de chaque connexion ? Quels FAI ?

Concernant Windows 7 et Windows 2008 c'est assez logique qu'ils aient exactement le même comportement vu que c'est le même noyau.

Cordialement.

Désoler mais le problème ne viens en aucun cas des connexion adsl, du réseaux en lui même, juste le fait de changer de système d'exploitation prouve que cela ne viens pas du réseaux local ou autre connexion adsl, le problème se situe au niveaux des système d’exploitation ou de la configuration des server. Désoler mais je trouve que les questions sont assez a coté de la plaque quel est le rapport avec le FAI des différente connexion adsl....

Désoler mais le problème ne viens en aucun cas des connexion adsl, du réseaux en lui même, juste le fait de changer de système d'exploitation prouve que cela ne viens pas du réseaux local ou autre connexion adsl, le problème se situe au niveaux des système d’exploitation ou de la configuration des server. Désoler mais je trouve que les questions sont assez a coté de la plaque quel est le rapport avec le FAI des différente connexion adsl....

La raison pour laquelle je pose ces questions est qu'à l'heure actuelle les trois seules explications qui pourraient avoir un sens pour moi sont:

• Une configuration différente des paramètres TCP pour les différentes connexions. Certains systèmes ont des algorithmes optimisant la taille de la fenêtre TCP (grosso modo la taille des données pouvant être à un moment m sur la connexion sans avoir été acquittées par le pair). La gestion de cette fenêtre peut être empirée par l'utilisation d'une connexion type ADSL, à débit asymétrique, si le lien de retour est engorgé par les acquittements.
• Une configuration différente des jumbo frames. Même si ici ça ne semble pas le cas.
• L'utilisation de routes différentes pour les deux tests, notamment si dans un cas le serveur est adressé en IPv4 et dans l'autre cas en IPv6

On peut éventuellement ajouter un module MPM apache différent (par exemple prefork dans un cas et worker dans l'autre) même si je ne vois pas où cela pourrait influer.

Si le débit est exactement le même, soit 20Mbps lorsque les serveurs sont adressés en local, les explications suivantes ne peuvent pas être retenues:

• Un problème de firewall ou d'antivirus
• Un problème de performances du serveur ou du système, entrainant une limitation du débit

De toute façon, dans la mesure où je n'ai jamais rencontré un tel cas, le seul juge de paix aurait pour moi été une capture wireshark effectuée sur les deux tests, idéalement sur les deux bouts de la connexion.

Cordialement.

Ha enfin des vraix questions. Nous ne sommes pas sur un réseaux d'entreprise, donc concernant l'activation du jumbo et des debits asymetric, on peut oublier, les piles IPV6 sont desactivées. Concernant le "TCP windows" mal configuré..., je continue mes recherches.

Ha enfin des vraix questions.

Ce ne sont pas des vraies questions, ce sont de fausses réponses !

Nous sommes pas sur un réseaux d'entreprise, donc concernant (...) des debits asymetric, on peut oublier

Le problème n'est pas en lui même le débit asymétrique de la ligne ADSL du client, mais il peut être mis en évidence par cela. Quelquechose d'intéressant est de voir le comportement de chacune des deux connexions en surchargeant respectivement le canal montant ou le canal descendant de la ligne ADSL du client par un flux UDP.

les piles IPV6 sont desactivées.

C'est une très mauvaise idée. Vous aurez bientôt des problèmes !

Concernant le "TCP windows" mal configuré..., je continue mes recherches.

Je ne dis pas nécessairement "mal configuré", je dis que les algorithmes ou paramètres par défaut peuvent être différents, et être moins bien adaptés à certaines utilisations.

Dans tous les cas j'aurais tendance à suggérer de faire varier tous les paramètres indépendamment:

• Plusieurs systèmes Windows différents: XP ou Windows Server 2003 (concernant Windows 7, c'était finalement une bonne idée, c'est Vista et non Seven qui a le même noyau que 2008).
• Plusieurs implémentations de serveurs HTTP différentes: IIS, NGinx, ou même le serveur HTTP de VLC
• Plusieurs connexions réseau client de type différent: tester avec des lignes à fort débit et à faible délai