Le pipelining HTTP c’est faire gérer au serveur une file de requêtes. Le navigateur envoie plusieurs requêtes à la suite les unes des autres sans attendre la réponse du serveur. Le serveur renvoie alors les réponses dès qu’il les a, potentiellement en parallèle aux requêtes du navigateur. Non seulement on utilise le principe de la connexion persistante, mais on évite d’attendre la réponse précédente avant d’envoyer la suite. Pour chaque ressource à télécharger après la première, c’est un aller-retour réseau à rien faire qui est évité.
Concrêtement
Si on considère que nos douze ressources sont téléchargées par un seul fil d’exécution (ou que vous avez 24 ressources, donc deux fils à 12), vous épargnez 11 aller-retour. Dans notre exemple c’est 440 ms qui sont gagnées avec tout ça.
Le seul défaut du pipelining est qu’il faut bien le régler dans le navigateur. Il peut devenir contre-performant dans un seul cas : si le navigateur enchaîne ses requêtes sur une seule connexion alors qu’il aurait pu les balancer sur plusieurs connexions simultanées. Il faut juste s’assurer que le navigateur préfère utiliser au maximum ses connexions multiples avant d’enchaîner les requêtes.
Le support
Le pipelining une fonctionnalité prévue par HTTP 1.1 (protocole que maintenant quasiment tous les serveurs web et proxys affirment implémenter). L’activer est un gain important pour le client, avec très peu de contre-coups pour le serveur.
Le problème ne vient alors pas vraiment d’un équilibre entre les performances clients et les performances serveurs, mais simplement de la capacité du serveur à enchaîner les requêtes. Il semblerait que certains serveurs supportent mal ou pas du tout cette possibilité, et entraînent des résultats incohérents : IIS par exemple.
C’est en tout cas pour cette raison que Firefox désactive le pipelining par défaut (mais documente la fonctionnalité). Le fait est que Opera utilise le pipelining depuis longtemps, et que cela n’a pas l’air de déranger ses utilisateurs ou de « casser le web ». IIS peut être détecté assez facilement et le reste du Web n’a pas l’air de poser un problème tel à Opera que cela justifie la désactivation pour Firefox.
Jouer avec firefox
Si vous voulez jouer avec Firefox, vous pouvez tout de même activer le pipelining via network.http.pipelining, network.http.proxy.pipelining, et network.http.pipelining.maxrequests. Les deux premiers sont des booléens, pour activer le pipelining. Le second est un nombre maximum de requêtes à mettre dans la pile, 4 est un bon défaut (Firefox n’accepte pas une valeur plus grande que 8, et de toutes façons elle n’aurai aucune utilité).
Bien entendu, le pipelining n’est disponible que sur HTTP 1.1, et si les connexions persitantes sont activées (dans le navigateur comme sur le serveur).
Attention à ne pas tirer de conclusions des réglages par défaut de Opera ou Safari. Leur part de marché respective n’engendre quasi aucun changement pour les serveurs.
Rik : il ne faut pas oublier IE8, avec sa parallélisation du JS et ses « six connections per host instead of two » !
Oui oui, j’en parlais sur http://performance.survol.fr/2008/04/limitation-du-nombre-de-requetes/ mais le pipelining arrive en plus. Avec 6 connexions persistantes simultanées, le gain du pipelining sera efficace dès que vous téléchargerez plus de 12 resources sur le même domaine. Maheureusement c’est assez fréquent.
Sunny: Je parlais pour cet article précis et du passage : « Le fait est que Opera utilise le pipelining depuis longtemps, et que cela n’a pas l’air de déranger ses utilisateurs ou de “casser le web” « .
Mais comme tu en parles, le changement de politique de IE me fait très peur et encore plus depuis que Firefox a décidé de suivre la tendance.
Pour ma part je suis assez confiant.
Pour les gros sites l’augmentation du nombre de connexions persistantes sera probablement sans casse sur les gros sites.
Pour schématiser chaque client prendra 3 fois plus de fils d’exécution, mais au final sera présent 3 fois moins de temps sur le serveur. Le nombre de processus à un instant T devrait être constant.
Le seul troublion est le keep-alive, car les connexions ouvertes le resteront encore un peu de temps après leur utilisation. Mais là aussi des gros sites dynamiques avec un keep-alive de plus de 2 secondes et sans CDN pour les ressources statiques (celles où ça aura une influence) ni reverse proxy en entrée, il n’y en a j’espère assez peu.
Le risque est sur les petits sites dynamiques où un processus coute cher et qui ont laissé la configuration par défaut de Apache 1.3 de 15s en keep-alive. Ceux là soufriront peut être un peu, mais peut être pas de quoi « casser le web » non plus.
Le pipelining, s’il y a de bonnes heuristiques pour savoir quels serveurs le supporte, j’ai du mal à voir le côté négatif. Le risque est essentiellement sur les clients (si jamais on tente un keep-alive qui ne fonctionne pas ou si un gros fichier retarde une queue de requête). Et là, côté client, même si Opera est minoritaire, sa base d’utilisateurs me parait suffisante pour dire « le web est utilisable et c’est jouable ».
Pour IE, ce sera 4 fois plus de connexions persistantes par client. Et je ne me fais pas trop peur pour les gros sites, ils ont les ressources pour foutre plus de machines.
Par contre, les petits serveurs vont pas pouvoir servir autant de personnes en simultané.
Et je maintiens, 1% d’Opera ne permet pas de tirer de conclusions. J’ai pas dit que ce serait mal, simplement que 1%, ça ne met pas les serveurs en situation difficile. C’est une situation marginale.
Au fait, quand je met le filtre pipelin, je me retrouve avec une quatrième valeur, une booléenne. Je le passe a true aussi?