Prise en charge du multiplexing ?

[julienrf]

Bonjour,
Merci pour votre outil qui est très simple et ergonomique.
Je vois que parmi les indicateurs principaux il y a le nombre de requêtes. Par contre, dans mon cas il indique 63 requêtes mais lorsque j’utilise un browser (Firefox ou Chrome), je vois que la plupart des requêtes sont traitées en parallèle (grâce au multiplexing permis par HTTP 2). En fait, si j’interprète correctement le graphique, je dénombre plutôt 14 requêtes :

Du coup ma question est : est-ce que EcoIndex sait utiliser le multiplexing et en tient compte dans son calcul ? Au cas où ça ne serait pas le cas, pensez-vous que ça serait un point important à ajouter ?

[tbroyer]

L'indicateur de requête d'EcoIndex correspond au nombre de requêtes HTTP, peu importe le nombre de connexions sur lesquelles elles sont réalisées, et donc indépendamment du multiplexing possible de HTTP/2 (comme les devtools des navigateurs, ou comme WebPageTest).
Dans l'image ci-dessus je dénombre 27 requêtes (27 lignes).

(note: le nombre de requêtes est utilisé comme estimation de la charge serveur pour générer la réponse –cf. https://www.ecoindex.fr/comment-ca-marche/–, donc indépendamment du transport HTTP/1.1 vs HTTP/2 vs HTTP/3)

[yaaax]

J'ajouterai que la page testée est scrollée jusqu'en bas, d'où peut-être la différence du nombre de requêtes.
Plus d'info dans le paragraphe "Méthodologie d'analyse"
https://www.ecoindex.fr/comment-ca-marche/

[vvatelot]

Je me suis aussi posé la question... Faut il en tenir compte ?
Pour l'instant ce n'est pas le cas, c'est sûr. Je pense qu'il faudrait "étoffer" l'ecoindex pour avoir:

• le nombre de requêtes totales
• le nombre de requête multiplexées
• le nombre d'hôtes différents sur lesquels on fait des requêtes

Encore une fois, l'ecoindex ne peut pas refléter un parcours utilisateur complet. À voir comment le faire évoluer. @julienrf souhaites tu participer à ce travail d'évolution ?

[julienrf]

Merci à tous pour vos réponses !

Est-ce qu’il serait possible d’en savoir plus sur le modèle utilisé ? Je vois l’implémentation ici mais je n’ai pas trouvé d’explication sur comment vous en êtes arrivés à ce modèle. (Edit: ah en fait je vois ça dans la doc « Les bornes de l’échelle de l’EcoIndex (0 à 100) ont été mises au point et validées en analysant la base HTTParchive (500 000 URLs). » Désolé j’avais lu en diagonale !)

Pourquoi pas contribuer oui. Cependant je ne sais pas vraiment comment modéliser correctement l’impact du nombre de connexions TCP vs requêtes HTTP. Est-ce que vous connaissez déjà des travaux qui ont été faits là-dessus ?

[vvatelot]

Je pense qu'on va rentrer dans des considérations techniques très complexes et il y a beaucoup de débats sur ces sujets...
Viens sur le chat https://chat.greenit.eco/ ... On est en train de voir pour créer des groupes de travail autour d'ecoindex.

[tbroyer]

Le nombre de requêtes HTTP étant utilisé dans l'EcoIndex comme une vague estimation de la charge serveur (rappelé encore il y a quelques jours par Frédéric Bordage, à l'origine de l'EcoIndex [1]), utiliser le nombre de connexions TCP (ou QUIC pour HTTP/3) n'a pas vraiment de sens.

Mesurer et quantifier l'utilisation du multiplexing est intéressant en terme d'optimisations, mais c'est plus du ressort d'outils comme EcoMeter ou GreenIT-Analysis, pas d'EcoIndex.

[1] https://groups.google.com/g/ecoconceptionweb/c/_E4rSsdKw-g/m/56PVQKMUDAAJ

Nous nous appuyons donc sur le nombre de requêtes HTTP pour évaluer la charge serveur. C'est le meilleur paramètre technique quantifié en notre possession lorsqu'on n'a pas un accès privilégié (donc intrusif) côté serveur. Et l'exemple de la Deutsch Bahn est intéressant à ce sujet. On imagine bien qu'entre la version ultra-light qui nécessite 2 req. HTTP en tout et pour tour pour obtenir l'horaire d'un train et la version "standard" qui mobilise 300 req. HTTP au total (soit 150 fois plus d'allers-retours entre le client et le serveur), il faudra plus de ressources physiques côté serveur pour servir le même nombre de clients.

[julienrf]

Merci pour le complément d’information. Cela dit ça me paraît très approximatif d’estimer la charge serveur comme ça. Une requête peut demander très peu de travail côté serveur (p. ex. servir des assets statiques) ou bien énormément (p. ex. une requête sur une base de données complexe et pas optimisée). Mais je comprends que c’est ce qu’on a de mieux :)

Le fait que le multiplexing a été introduit dans HTTP/2 pour rendre le web plus efficace montre à mon avis que c’est un indicateur pertinent. Mais peut-être que c’est hors périmètre pour EcoIndex comme tu dis… Je vais me renseigner sur EcoMeter et GreenIT-Analysis.

[julienrf]

J’ai ouvert la discussion #299 qui se concentre plus particulièrement sur les solutions pour affiner l’estimation des impacts côté serveur.