Commentaires sur : Impact de la latence réseau

Par : Latence et CDN —Performance web

Latence et CDN —Performance web — Wed, 03 Jun 2009 15:24:04 +0000

[…] La latence est une des composantes qui pénalise le plus les performances actuellement. Les connexions Internet françaises se font plutôt à haut débit, et même un mauvais wifi laisse finalement passer assez de trafic pour que ce soit viable. Par contre, avec l’explosion du nombre de composants par page, la latence est probablement le facteur le plus limitant. 40 composants à 50ms de latence, c’est 2 secondes de perdues. Même en imaginant utiliser deux fils de téléchargement, c’est encore une seconde d’attente. Sur une mauvaise connexion (wifi ?) ou quand on s’adresse à un site qui n’a pas de serveur en France (ou très proche), la latence peut vite exploser. Je ne parle même pas de ce que pourraient nous apporter HAOPI et LOPSI2 s’ils filtrent les accès côté FAI (on peut leur faire confiance pour affirmer que les débits ne bougeront pas, mais en ce qui concerne la latence…). À 120ms de latence c’est d’un coup plusieurs secondes qui partent en fumée. En fait ce sont souvent les publicités qui ont la plus grande latence. Quand le javascript qui gère la pub est bloquant et qu’on a deux ou trois redirections HTTP, on peut facilement perdre une seconde. Si vous ne me croyez pas, regardez l’exemple de Right Media. […]

Par : Éric

Éric — Mon, 31 Mar 2008 13:36:49 +0000

@mat:
Sur ce genre de taille, je doute que je serveur réagisse tellement différemment. Même lui sera moins chargé avec une petite requête (car elle reste petite) que deux très petite.

Reste que oui, comme pour ton commentaire précédent, il y a plein de facteurs. Il n’y a pas de solution universelle, mais je peux dire sans risque ici que le gain sera sensible. Les cas exceptionnels ou cas spéciaux existent, mais cela ne m’empêchera pas de publier des solutions qui auront toutes les chances d’être vrai dans la grande majorité des cas.

Par : Éric

Éric — Mon, 31 Mar 2008 13:24:20 +0000

Ah, je vois ce que tu veux dire. Effectivement. On gagne 25ms par fil d’exécution, mais ces 25ms sont gagnés en parallèle, donc ne se cumulent pas.

Par : Rik

Rik — Mon, 31 Mar 2008 12:48:28 +0000

Je parlais du temps. On ne gagne pas 50ms mais 25 seulement.

Par : Éric

Éric — Mon, 31 Mar 2008 08:15:36 +0000

Même si les images sont téléchargées en parallèle, et même si les connexions sont déjà ouvertes en keep-alive, on gagne quand même un aller-retour réseau à chaque fichier en moins.
Ce qu’éventuellement on ne gagne pas (et que je n’ai pas compté ici), c’est l’établissement de la connexion tcp, qui peut prendre parfois du temps.

Par : mat

mat — Mon, 31 Mar 2008 01:33:16 +0000

« Si je les concatène pour en faire un seul, je gagne d’un coup 3 aller-retours, soit 60 ms »

Ah non!. Tu n’as aucune idée de ce que tu gagnes ici, c’est purement théorique. Le serveur peut réagir totalement différemment avec des téléchargements de fichier plus gros (en bien comme en mal), c’est impossible à prévoir. Un effet pervers que ca peut avoir, par exemple, est ce chaque connexion au serveur dure plus longtemps: en cas de grosse bourre, genre un passage sur digg/slashdot, ca pourrait risquer de bouffer un à un tous les slots du serveur HTTP, rendant le site indisponible. Gaffe, donc 🙂

Ca fait partie d’une masse de trucs ce que je voulais dire mais que j’ai eu la flemme d’écrire sur ton premier post: il faut faire très attention à la théorie, on ne peut jamais prévoir exactement ce qui peut se passer. Quelquefois, une optimisation parfaitement logique, faisant gagner un max de perfs en théorie, peut complètement tout casser…

Par : Rik

Rik — Sun, 30 Mar 2008 23:59:11 +0000

Petite précision concernant les images, on ne gagne que la moitié des allers retours puisqu’il y a deux téléchargements en parallèle.