#varnish

avec #varnish déjà tu peux te protéger

il faut utiliser mod_rpaf cf. ►http://zzz.rezo.net/Terminer-l-installation-de-Varnish.html

N’est-il pas possible d’avoir plusieurs entêtes HTTP_X_FORWARDED_FOR ? J’entends : si un visiteur est derrière un proxy, et que ce proxy ajoute un tel entête, que fait Varnish ? Il conserve tous les entêtes ? Il les garde tous ? En choisit un parmi d’autres ?

c’est pas une bonne idée les HTTP_X_FORWARDED_FOR si tu ne contrôles pas qui les a envoyées : sinon c’est trop facile à ajouter dans ta requête pour te faire passer pour un membre du réseau local ; mod_rpaf résoud tout ça :-)

Merci @fil. Voici donc ma nouvelle config :

– J’installe mod_rpaf (ici, Debian) :
http://pastebin.com/DWR5RNhn

– Configuration de mods-enabled/rpaf.conf :
http://pastebin.com/nCNzzTLD

RPAFproxy_ips est l’IP du serveur qui héberge Varnish (si Varnish et Apache sur la même machine, c’est donc l’IP de la machine elle-même). J’ai l’impression que la variable « RPAFheader » donnée dans la doc est dépréciée (en fait, Apache la signale carrément comme une erreur).

– Dans /etc/varnish/default.vcl, je tape plus large (je balance systématiquement l’IP dans x-forwarded-for. S’il y a déjà quelque chose dans x-forwarded-for, je le conserve.
http://pastebin.com/BGU6d4tb

voilà ; et surtout tu ne bidouilles pas côté PHP, car le fait que la requête passe par un proxy ne doit pas concerner ton application

Effectivement : ne jamais utiliser X-Forwarded-For comme si c’était un header valide, ça peut très bien être n’importe quoi si c’est envoyé par le client (d’ailleurs c’est ce que je fait, cf. IPFuck pour Firefox). D’ailleurs normalement ça sert à rien de le stocker, même pour une requête légale (peu importe que l’IP qui se connecte au site soit un proxy, un routeur d’entreprise ou un particulier, la loi demande de stocker l’IP qui se connecte c’est tout).

http://seenthis.net/messages/3885

Visiblement, ces articles reposent sur une configuration dans laquelle le cache de Varnish est un fichier de 1Go sur le disque dur.

Il faut configurer Varnish pour passer le cache en mémoire vive. Et là ça devient juste sidérant.

Je recommande aussi #Varnish (voir le tag)

J’ai fait un article un peu plus détaillé ►http://www.bortzmeyer.org/limit-apache.html

Ça semble très efficace. Tu l’utilises ?

Je l’utilise sur Flip-Zone et sur Seenthis. C’est une tuerie :
– la charge sur le serveur est incroyablement allégée,
– la vitesse de consultation est ultra-fluide.

Et autres avantages, comme l’indique Fil :
– si le serveur Apache plante, le site continuera à être livré sur le cache de Varnish,
– tu peux faire du load balancing très simplement (je ne le fais pas, mais bon, si jamais...),
– truc marrant : quand j’ai déménagé Seenthis sur le nouveau serveur, donc changement au niveau du DNS, l’ancien serveur avait son Varnish qui pointait les requêtes vers la nouveau serveur, de manière totalement transparente pour les visiteurs.

La suite : installer Varnish
http://zzz.rezo.net/Installer-Varnish.html

la suite : Interfacer Varnish & SPIP
http://zzz.rezo.net/Interfacer-Varnish-SPIP.html

avec la config pour #varnish et le plugin pour #spip qui se parlent intelligemment

suite & fin : terminer l’installation
►http://zzz.rezo.net/Terminer-l-installation-de-Varnish.html

j’ai tout regroupé dans http://zzz.rezo.net/-Varnish-.html

Pour avoir une mesure objective, j’utilise #google webmaster tools => labos => #Performances du site. Mais hélas les données ont souvent un mois de retard, difficile de voir si l’installation d’un meilleur #cache ou d’un #varnish a un effet mesuré dans le monde réel.

On m’a suggéré récemment un cron sur un nombre significatif de pages, depuis différents serveurs... C’est débile ou il y a de l’idée ?

@fil Oui, je fais ça et, oui, ça prend parfois des semaines pour obtenir une mise à jour. Là, l’idée c’est que je constate du jour au lendemain une très forte augmentation du nombre de pages vues par visites, donc il y a bien eu un impact quelque part.

@suske Il n’y a pas grand intérêt à mesurer la « vitesse » des pages d’un site dans l’absolu. Flip-Zone a des pages « lourdes », parce qu’elles contiennent beaucoup de choses (animation Flash tourne-pages) et que, d’après les stats, les utilisatrices passent beaucoup de temps à consulter une même page. Pour moi, la seule chose qui soit mesurable, c’est de mesurer un changement par rapport à « avant », et surtout du comportement des utilisatrices. Et là, dans tous les cas, il y a une forte dose de pifomètre (et, au final, les boîtes pour qui ça compte fortement ne mesure rien dans l’absolu : elles font des test A/B pour voir quelle solution est la plus efficace).

Pour faire des tests de perfs côté front, je recommande vivement http://webpagetest.org #webperf

merci de m’avoir prévenu LOL WTF

à bien y réfléchir il serait très aisé d’ajouter l’option suivante dans ce plugin : remplacer l’inclusion par un <esi : url de l’inclusion>
#varnish

Si tu regardes le fichier /inc, tu verras qu’il y a déjà une fonction :
_esi_microcache()
qui fait exactement cela.

Mais je n’arrive pas à faire fonctionner les fonctions ESI.

Sinon, ça serait intéressant :
– puisqu’il s’agit d’un plugin, il sera sans doute possible de détecter la présence du code <esi : dans le source, et d’ajouter un header destiné à Varnish pour que celui-ci parse cette page spécifiquement ;
– ensuite, dans supprimer_microcache, être capable de forcer la purge pour cette adresse.

Et, au final, faire que ça tourne directement sur la fonction microcache, sans modification, uniquement sur une variable de configuration (pour que les mêmes squelettes fonctionnent avec ou sans ESI Varnish).

Sinon, tu as déjà réussi à utiliser les fonctionnalités ESI ?
►http://www.varnish-cache.org/trac/wiki/ESIfeatures

Pas essayé ; pour l’instant je me focalise sur le cache & #SPIP ; gestion des stats en javascript, invalidation (#purge) du #cache depuis SPIP. Ca marche bien.

Parce que je pensais : si on parvient à utiliser ESI, il sera très facile de faire placer des ordres d’insertion ESI directement par microcache. Et avec ton #purge, même récupérer ma fonctionnalité d’effacement du microcache.

Puis... tester pour voir si ça a le moindre intérêt en terme de performances.

la technique de posterous semble correspondre à ton cas
http://technology.posterous.com/making-posterous-faster-with-varnish

Merci d’avoir pris le temps de me répondre.
J’ai un moyen de contourner l’obstacle ?
Parce que c’est très frustrant de ne pas avoir accès à ce service +

Au temps pour moi : ça marche, àa marche ! Quoi que tu as fait, @seenthis ?
Trop contente je suis !

Pour ceux qui sont connectés : n’est-il pas possible de pré-sélectionner une langue comme tu le fais en PHP, {{mais}} d’avoir la sélection explicite dans mon profil utilisateur ? Comme ça si je vais dans un cyber-café ukrainien, c’est quand même celle de mon compte qui est utilisée. :)

@rastapopoulos a raison, c’est le plus simple.

Voilà, ça devrait être stable désormais. Il reste des choses à faire sur le serveur, mais en gros, ça devrait tourner.

Donc :
– #Seenthis est sur un gros serveur pour lui tout seul ; auparavant, il partageait la vedette avec ►http://www.flip-zone.com, qui bouffe déjà beaucoup de ressource ;
– à l’instant, on passe par le #Varnish de l’ancien serveur, qui rebalance vers le nouveau serveur ; dès que les DNS seront à jour, on devrait directement taper sur le nouveau serveur.

bien joué !

J’ai l’impression que je n’ai plus la récupération des sites distants.

OK, les sites distants sont revenus. Problème de droits sur le serveur. Du coup, retour de la détermination de la langue et de la thématisation.

Question intéressante quand même : comment je fais pour récupérer la différence d’horloge entre le serveur et le visiteur, dès lors que le serveur est planqué derrière #Varnish ?

OK, j’ai trouvé : je demande la page d’accueil du serveur avec un POST, et j’extrais la date de la réponse. C’est le fonctionnement désormais. En revanche, il faudrait que je réponde avec un fichier ultra-light, tant qu’à faire. Je vais ajouter un fichier html bidon dans mon plugin, et le faire appeler par le script.

Oualà... avec un petit rien, ça prend 30 millisecondes, et je n’ai plus besoin du moindre truc dynamique côté serveur. Ça me semble un compromis acceptable.

juste pour dire, ce souci est désormais corrigé autrement : le décalage de la date du serveur SQL (et non pas d’apache, dans l’hypothèse où ce seraient deux serveurs différents), est conservé dans un cookie pour éviter de l’appeler à chaque affichage de page
http://zone.spip.org/trac/spip-zone/changeset/68577

et pour les vieilles dates : là on affiche « 18/12/2010 18:43 », ne serait-ce pas mieux « 18 déc. 2010 » (sans indication d’heure ?)

Si, ce serait mieux.

#ne_me_demandez_pas_comment_je_suis_arrive_ici_j_en_sais_rien ^^

La doc des fonctionnalités #ESI dans #Varnish :
►http://www.varnish-cache.org/trac/wiki/ESIfeatures

Controlling Varnish ESI inside your application http://blog.raspberry.nl/2010/07/05/controlling-varnish-esi-inside-your-application

Bon, pour l’instant, je n’arrive pas du tout à activer ESI dans mon Varnish.

Sauf erreur:
sub vcl_fetch
{
if (req.http.host ~ „seenthis“) {
set beresp.ttl = 300s;
}
}

Ça marche ! #seenthis_done : le message précédent est apparu au bout de cinq minutes sur un client non connecté. Les visiteurs identifiés passent au travers de Varnish.