Extension Fasterfox : une plaie pour les serveurs ?

c'est serait vraiment trop c** que FF soit blacklisté pour ca quand même...

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 ...

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+

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.

Les onglets sont les amis des internautes et des serveurs :o

Est-ce que quelqu'un a fait des tests sur le robots.txt ?

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



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"...
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.

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.

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)

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.