5139 sujets

Le Bar du forum

Pages :
Administrateur
Bonjour à tous,

J'aimerais en savoir plus et entamer un débat (s'il y'a lieu d'en avoir un) sur l'extension Fasterfox, dont l'utilité est d'accélérer les chargements de pages web. Le principe de mettre en cache les autres pages du site en tâche de fond, pour les charger plus rapidement ensuite.

Je viens d'avoir une discussion avec Mateo du Site du Zéro et il semblerait que cette extension, qui fait partie des extensions les plus téléchargées pose de véritables problèmes aux serveurs et aux bandes passantes.

Le plugin analyse le code html de la page à la recherche de liens. Il prend tous les liens qu'il voit et se met à charger en fond les pages correspondantes, qu'il met en cache.
Ce qui fait que le serveur pour une personne reçoit facilement 40 requêtes de pages supplémentaires simultanément, sans parler du fait évident qu'il y a gaspillage (le type n'ira jamais voir toutes ces pages qui ont été préchargées).

Mateo explique le cas en prenant l'exemple du Site du Zéro :
Mateo a écrit :
prenons 300 zéros connectés. Disons que 10 d'entre eux ont fasterfox (chiffre pas du tout surestimé bien au contraire). On a constaté des gens qui faisaient 40 pages par seconde, cela veut dire 400 requêtes par seconde simultanément (soit environ 4000 requêtes MySQL), ce qui fait un peu plus de 700 zéros connectés virtuellement.
Notre serveur mysql ne tenait plus (et je pense qu'on n'a pas fini de lutter)


Ce plugin a plusieurs modes. Par défaut il se met en turbo et ne respecte pas les recommandations RFC, or en mode turbo firefox se met à télécharger en fond tous les liens des pages que l'on visite en augmentant considérablement la charge des serveurs.

Il paraîtrait que certains sites commencent à bloquer firefox pour ces raisons (quand ils détectent le prefetch), dnsstuff.com par exemple.

J'aimerais avoir vos avis plus éclairés que moi à ce sujet. Si cela s'avère vérifié, il faudrait peut-être diffuser massivement ce genre d'informations à Mozilla et aux webmasters en général. Qu'en pensez-vous ?

EDIT : autres sources de discussions sur le sujet :
- Electronic Arts forum
- Whirlpool forums
Modifié par Raphael (06 Dec 2005 - 15:14)
On n'a pas fini d'en voir qui utilisent ce genre de joujou je crois... J'en connais qui trouvent que le 8megabit c'est pas assez rapide et qui utilisent cette m.... C'est bien les soft ouverts, mais ça laisse plein d'utilisations possibles. Trop sans doute. Quant à bloquer les nav qui préfètchent, je voudrais bien savoir comment on peut faire ça... Faudrait analyser le nombre de requète par seconde de chaque utilisateur ? Ca boufferait pas davantage de ressources serveur ?
Bonsoir,
Argl c'est n'importe nawak ce truc ! Quel gâchis... le jour où un visiteur cliquera systématiquement sur les 400 liens de chaque page... on pourrait presque assimiler ça à un aspirateur
C'est pour moi une extension totalement inutile !

Je n'en vois même pas l'intérêt : qui va regarder toutes les pages d'un site web ??? Surtout que certains sites sont très bien fournis en nombres de pages. C'est vraiment un gros gaspillage de ressources ... Smiley ohwell
Étant le traducteur de cette extension, je me sens concerné.

Je pourrais faire quelques suggestions à l'auteur :
- Est-ce qu'il respecte les règles robots.txt ? Si non, alors il est indispensable que ce soit le cas pour la version 1.0 en préparation
- Avec Firefox 1.5, il est possible d'ajouter (par exemple) "Fasterfox/0.8.1" à la chaine UserAgent. Est-ce que cela pourrait être utile ? Est-ce une proposition à lui faire ?
- Par défaut, respecter les RFC…

Mais avant ça, il me faut votre avis. Est-ce que ce genre de mesures pourrait être efficace ?
Ah mon avis, le fait d'ajouter Fasterfox dans le UserAgent peut faciliter le blocage des internautes surfant avec cette extension. Ou du moins leur imposer un temps entre chaque requête...

Le respect des fichiers robots.txt peut s'avérer très intéressant afin de ne pas pénaliser l'internaute mais toutefois désactiver SaferFox. Mais je ne connais pas bien les fichiers robots.txt donc je ne sais pas si c'est fesable facilement...

Voili voilou...

a+
Administrateur
Je clique sur les liens en les ouvrant dans un onglet en arrière-plan (càd que je reste sur la page d'origine), le temps de finir de lire la page en cours, les onglets ouverts sont chargés depuis longtemps. Smiley bignoel

Les onglets sont les amis des internautes et des serveurs :o
Calimo a écrit :
Étant le traducteur de cette extension, je me sens concerné.

Je pourrais faire quelques suggestions à l'auteur :
- Est-ce qu'il respecte les règles robots.txt ? Si non, alors il est indispensable que ce soit le cas pour la version 1.0 en préparation
- Avec Firefox 1.5, il est possible d'ajouter (par exemple) "Fasterfox/0.8.1" à la chaine UserAgent. Est-ce que cela pourrait être utile ? Est-ce une proposition à lui faire ?
- Par défaut, respecter les RFC…

Mais avant ça, il me faut votre avis. Est-ce que ce genre de mesures pourrait être efficace ?


J'aime assez ces mesures.

Il faudrait aussi permettre au webmaster, plutôt que de bannir systèmatiquement l'internaute qui n'est pas forcément au courant des "ravages" que peut provoquer cette extension, la possibilité de désactiver la fonctionnalité "aspirateur" Fasterfox pendant la visite d'un site, par exemple via une balise meta ou un entête HTTP (je ne sais pas si on peut envoyer des entêtes spécifiques). Et prévenir l'utilisateur que ça a été désactivé (au hasard, via une icône dans la barre d'état).
Je lis dans un rapport de bug enflammé de la part d'un webmaster dont le serveur a crashé (mais Fasterfox n'est pas la seule en cause, il y a visiblement un "effet slashdot" à petite échelle), qu'il est possible d'utiliser l'entête X-moz: prefetch pour savoir s'il s'agit d'une requête de préchargement.

À noter que le préchargement est aussi fait de manière "smart" dans certains cas, par exemple sur le premier résultat de Google.
Calimo > selon moi, cette extension ne devrait pas proposer du tout le mode turbo. Quitte à faire du prefetching, autant respecter au moins les recommandations RFC. C'est la base de la base quand même.
Alors le mode turbo par défaut, je vous laisse imaginer les dégâts !


Nous n'avons pas testé les règles robots.txt mais vu qu'il ne respecte pas les RFC je ne vois pas pourquoi il se mettrait à respecter les robots.txt. Ce n'est pas une mauvaise idée ceci dit.

Ajouter une info fasterfox à la chaîne UserAgent me paraît important mais pas indispensable.
Ce qui est fondamental c'est qu'il indique le header X-moz : prefetch. Je crois que c'est déjà le cas, on est arrivés à le bloquer sur le Site du Zér0 et devinez quoi... depuis c'est super rapide !


Quoiqu'il en soit, il me semble clair qu'une plus grande sensibilisation de l'utilisateur serait utile. Un message "Attention, vous augmentez la charge des serveurs" devrait s'afficher la première fois qu'on utilise l'extension au moins.
Malheureusement une telle extension qui devient si populaire c'est carrément problématique pour les serveurs Smiley decu



Smiley edit calimo > tu dis que le préchargement est fait de manière douce sur google, il n'en est rien sur le site du zéro. Le plugin voit des pages html de partout et se dit "chouette, des pages statiques, je peux précharger comme un barbare !"... Alors qu'en réalité nous faisons de l'url rewriting et que par conséquent nos pages sont tout sauf statiques.

En fait, notre découverte de Fasterfox vient d'un rapport de bug qu'on nous a fait : on nous a plusieurs fois signalé que certaines personnes se faisaient déconnecter au bout de quelques minutes.
Cela n'avait pas de sens pour nous à l'époque car, mis à part le timeout, rien ne déconnectait aussi aléatoirement les membres du site.
Maintenant, nous avons compris pourquoi : fasterfox préchargeait la page "deconnexion.html"... Smiley biggol
Modifié par M@teo21 (06 Dec 2005 - 22:24)
Calimo a écrit :
Je lis dans un rapport de bug enflammé de la part d'un webmaster dont le serveur a crashé (mais Fasterfox n'est pas la seule en cause, il y a visiblement un "effet slashdot" à petite échelle), qu'il est possible d'utiliser l'entête X-moz: prefetch pour savoir s'il s'agit d'une requête de préchargement.

À noter que le préchargement est aussi fait de manière "smart" dans certains cas, par exemple sur le premier résultat de Google.


Voir dans cette entrée de la faq Mozilla: Link Prefetching FAQ [en ].

Ainsi que la page de la faq google: Questions concernant la pré-extraction (prefetching) des résultats.

Dont la dernière entrée précise:
a écrit :
3. Je souhaite bloquer ou ne pas tenir compte des requêtes de pré-extraction. Que dois-je faire ?

Si vous souhaitez bloquer ou ne pas tenir compte des requêtes de pré-extraction (de Google et d'autres sites Web), vous devez configurer votre serveur Web de sorte qu'il renvoie un code de réponse HTTP 404 pour les requêtes comportant l'en-tête « X-moz: prefetch ».


Ce qui n'est pas neutre.

Une extension que pour ma part je ne souhaiterais pas voir se développer plus avant, les effets positifs sont minimes (pour l'utilisateur) et clairement pénibles, dangereux et anormalement consommateur de ressources pour les serveurs (les hébergeurs mutualisés par exemple), couteux pour ceux qui font héberger leurs sites. Une économie et une écologie des ressources numériques reste probablement à inventer.

A mon avis, Calimo la solution serait qu'il n'y ait pas de traduction en français. Smiley murf
Cette histoire de RFC c'est un peu du vent.

Tout d'abord, pour comprendre un peu mieux de quoi on parle, il s'agit de la RFC 2616. Il y a dit que les clients ne devraient pas utiliser plus de 2 connexions persistantes simultanées par serveur ("SHOULD NOT", le should ayant un poids assez fort dans les RFC).

Maintenant :
- Cette RFC décrit l'état de l'art en 1999. Depuis les débits et surtout le nombre de ressources liées a explosé. Quand on charge une page il n'est maintenant plus rare d'avoir une dizaine de fichiers graphiques, une ou deux CSS, un ou deux fichiers javascript, une déclaration p3p et j'en passe. Les capacités des serveurs ont aussi bien augmenté. Si on remet ça au gout actuel, il n'est pas totalement idiot de penser qu'on puisse monter à 4.
- Il est fréquent d'outrepasser les RFC. Elles sont souvent rédigées à fortiori pour dire "actuellement voilà comment ça se passe", et pas à priori pour dire "voilà comme ça va se passer". S'il ne fallait pas outrepasser les RFC ce site n'existerait pas (la RFC s'est arrêtée à HTML 4.0). Bref, aller plus loin qu'une RFC c'est super fréquent, surtout une RFC de 6 ans sur un détail de performance (qui a bien changé depuis).

Je me demande même si par défaut le nombre de connexions simultanées par domaine n'est pas de 4 sur un IE/win classique. Pourtant personne n'a crié au scandale jusqu'à présent.
Si par contre le robots.txt n'est pas respecté c'est beaucoup plus contestable, parce que là il y a une volonté expresse de l'auteur ou du responsable du site Web.



Qu'on soit clair, ce qui gêne tout le monde c'est que l'extension fasse des dizaines de requêtes par avance, donc la majorité sont inutiles. Qu'il les fasse en simultané ou pas influe en fait relativement peu.
Google Accelerator a engendré la même polémique, pour les mêmes causes.
Malheureusement ce phénomène n'est pas prêt de s'arrêter et ne pourra être endigué qu'avec un truc bien connu : les proxy.


Est-ce qu'il ne serait pas temps que les FAI remettent en route les proxy qu'ils avaient avant ?
Ca règle le problème des RSS, des prefetch et de la charge réseau des serveurs de publication (ceux qui n'ont pas un contenu totalement dynamique qui change à chaque microseconde).
Certes, ces extensions ne sont pas très respectueuses à faire des requêtes à tort et à travers, mais AMHA le problème principal c'est surtout les FAI qui ont commencé à dire "boaf, avec la bande passante qui devient moins chère, on va arrêter de fournir des proxy". Ils n'ont vu que leur problématique interne, et pas les conséquences chez les hébergeurs.
M@teo21 a écrit :
Smiley edit calimo > tu dis que le préchargement est fait de manière douce sur google, il n'en est rien sur le site du zéro. Le plugin voit des pages html de partout et se dit "chouette, des pages statiques, je peux précharger comme un barbare !"... Alors qu'en réalité nous faisons de l'url rewriting et que par conséquent nos pages sont tout sauf statiques.

En fait là je parlais d'un comportement par défaut de Firefox (donc sans l'extension).
Nativement, le premier résultat d'une recherche Google est préfetché. Parce que Google inclut un attribut rel="prefetch" sur le premier lien trouvé.

Mais c'est sur qu'avec cette extension, tout est préfetché.

N'hésitez pas à faire part de vos craintes/menaces (de blacklistage et cie) à l'auteur. http://fasterfox.mozdev.org/contact.html
Il est très ouvert et tout à fait prêt à se remettre en question s'il y a des arguments valables. Il n'a pas hésité à modifier pas mal de choses pour "coller" aux localisations, et je pense qu'il sera prêt aussi à rendre l'extension plus "smart" pour en assurer la pérennité Smiley cligne

PS : l'extension inclut aussi toute une série d'amélioration côté client qui n'interfère pas le moins du monde avec les serveurs (retour rapide, délai de rendu initial, etc.)
Salut,

Calimo > les améliorations côté client c'est très bien.
Mais quand ça touche au serveur, c'est un autre problème !


Ganf > je n'ai fait que des suppositions pour le robots.txt, je n'ai jamais dit qu'il n'était pas respecté (mais je le pense ^^)
On est quand même TRES loin des RFC en mode turbo d'après ce qu'on a vu. Nos visiteurs prefetch 40 pages simultanément dans la même seconde. Dans de telles conditions, il me paraît normal que notre serveur ait autant tiré la gueule (on ne dispose pas de moyens infinis comme on l'a dit).

La bande passante n'est pas mon problème, mon problème c'est la capacité du serveur lui-même à répondre à autant de requêtes. Oublie donc le souci de bande passante pour le moment (je ne suis en tout cas pas près d'avoir à y faire face).
Entre 4 et 40 connexions simultanées, je pense qu'il y a une marge non négligeable. Et 40, vous en conviendrez, c'est un tantinet exagéré !
Il y a également un problème dont j'aimerais discuter :

Comme vous l'avez dit, les RFC sont assez peu souvent totalement respectées. Ainsi, la RFC HTTP indique que seule une requête de type POST doit modifier du contenu, et non une requête GET.

Mais moi, dans un souci d'ergonomie, je ne respecte pas entièrement cette règle, de même que beaucoup de webmasters. Par exemple : sur Agrégaweb, sur la page "Vos flux", vous pouvez modifier l'ordre d'affichage des flux en cliquant sur les liens "Monter" ou "Descendre". Sauf que ces liens sont des requêtes GET, url-rewritées qui plus est; exemples :

http://www.agregaweb.net/flux/monter/41/
http://www.agregaweb.net/flux/descendre/52/

Imaginez un instant ce qui se passerait si Fasterfox préfetchait ces liens sans demander quoi que ce soit à l'utilisateur...
Modifié par e-t172 (07 Dec 2005 - 12:43)
Administrateur
C'est justement ce qui se produisait avec Google web accelerator, qui est sur le point de refaire surface. Et là, ça va faire mille fois plus mal que Fasterfox.
> Nos visiteurs prefetch 40 pages simultanément dans la même seconde.

Attention, si tu parles de la RFC ils parlent de connexions réellement simultanées. Ce n'est pas l'information que te retournent les outils de statistiques ou les applications (qui elles regardent le nombre de connexions dans un laps de temps relativement court).

Si tes pages mettent 100ms à venir (ce qui ne me parait irréaliste si ton serveur a de la bande passante et qu'on parle de plein de petits fichiers HTML/js/css zippés), on peut faire 20 requêtes/pages dans la même seconde en respectant la RFC.

(ceci dit je suis d'accord, faire 40 requêtes de prefetch c'est abusé, si elles sont faites trop rapidement et pas étalées dans le temps c'est encore pire).
Pages :