LES CONTES DU COCKATOO
▻https://www.youtube.com/watch?v=hjRE0UJV4pw
Quatre personnages ordinaires à qui il arrive des choses extraordinaires....OK.
#film #absurde #rap #musique #comédie_musicale #Les_frères_de_la_piscine #Varnish #Makala #Suisse
LES CONTES DU COCKATOO
▻https://www.youtube.com/watch?v=hjRE0UJV4pw
Quatre personnages ordinaires à qui il arrive des choses extraordinaires....OK.
#film #absurde #rap #musique #comédie_musicale #Les_frères_de_la_piscine #Varnish #Makala #Suisse
Est-ce que quelqu’un a une version de la config Varnish pour SPIP, telle qu’on la trouve par exemple là :
►http://zzz.rezo.net/Interfacer-Varnish-SPIP.html
mais qui fonctionnerait avec un Varnish récent (VCL 4.0) ?
Ah zut:
Error:
Message from VCC-compiler:
Invalid return "fetch"
('/etc/varnish/default.vcl' Line 391 Pos 14)
return(fetch);
-------------#####--
...in subroutine "vcl_hit"
('/etc/varnish/default.vcl' Line 366 Pos 5)
sub vcl_hit {
----#######--
...which is the "vcl_hit" method
Legal returns are: "deliver" "miss" "pass" "restart" "synth"
Running VCC-compiler failed, exited with 2
VCL compilation failed
Sauf erreur : en remplaçant les return(fetch)
par des return(miss)
, ça fonctionne.
Bon, la grosse galère, c’était (sur une Debian toute neuve) de trouver pourquoi Varnish ne répondait pas sur le port 80. C’est parce que l’habituel fichier /etc/default/varnish
n’est pas utilisé : la config de lancement de Varnish se fait dans /lib/systemd/system/varnish.service
Doc ici :
▻https://docs.varnish-software.com/tutorials/configuring-systemd-services
Encore fête : une mise à jour qui a cassé le démarrage de Varnish…
Quand il y a plusieurs ports indiqués dans varnishd
séparés par une virgule, il faut maintenant remettre -a
à chaque fois :
varnishd … -F - a :80, :443 -T localhost:6082…
varnishd … -F - a :80, -a :443 -T localhost:6082…
Trouvé ça en réponse à l’erreur de démarrage « Unknown protocol » :
▻https://varnish-cache.org/lists/pipermail/varnish-bugs/2015-March/007053.html
#Varnish et #Drupal : gérer un cache anonyme étendu
▻https://makina-corpus.com/blog/metier/2018/varnish-et-drupal-gerer-un-cache-anonyme-etendu
Le rôle d’un Reverse Proxy Cache Varnish dans une architecture Web (type Drupal).
How to get started with #Varnish Cache 5.0 with experimental #HTTP/2 support
▻https://info.varnish-software.com/blog/varnish-cache-5-http2-support
Varnish Cache 5.0 is now available. In Varnish Cache 5.0 there is experimental support for HTTP/2. By “experimental” we mean that it works, but we haven’t had any big production sites on it yet. We are eager for you to use it, test it and get your hands dirty with it and to get your input.
Here is how you enable it:
1) Install Varnish Cache 5.0.0.
2) Install #Hitch TLS proxy (www.hitch-tls.org) with ALPN support for terminating client TLS.
3) Configure ALPN, PROXYv2 and finally HTTP/2!
À propos de l’hébergement de seenthis.net
Après la panne (définitive) de la dedibox d’@arno où #seenthis était installé au départ, le site a migré sur le serveur de @rezo.
Il y tourne depuis un moment sans problème de charge ni d’espace disque, et peut continuer à tourner ainsi un certain temps. Nous ne sommes donc pas contraints par l’urgence.
Mais à moyen terme cette situation n’est pas désirable, ni pour moi (qui ne souhaite pas héberger les contenus d’un site ouvert au public), ni pour le projet (qui ne devrait pas reposer sur une seule personne).
Je souhaite donc (en accord avec @arno) que se mette en place un groupe qui prenne en charge cet hébergement à tous points de vue (disons : démocratique, financier, technique et administratif). Nous participerions à ce groupe.
Description technique
Basé sur #SPIP, seenthis.net nécessite à l’heure actuelle un dispositif #LAMP ; son moteur de recherche utilise #Sphinx ; on emploie #Varnish en front pour alléger le trafic sur Apache, et #memcached pour le cache interne.
Des backups quotidiens hors-site sont automatisés (et vérifiés de façon régulière). Les notifications sont envoyées via postfix (et parfois via #mandrill quand ça coince au niveau réception).
Les utilisateurs remontent régulièrement :
-- le besoin d’ajouter https sur le serveur (avec un certificat #letsencrypt)
-- le fait que les mails de notification tombent souvent en spam
Évolutivité
On aimerait aussi que le serveur ne bloque pas les pistes de développement qu’on peut déjà avoir en tête :
-- d’envoyer des mails à quelqu’un (pour des messages privés)
-- de récupérer/synchroniser ses messages via github/rsync/
-- d’avoir plusieurs instances communiquant en réseau (à la mode diaspora*) / révision de l’API / branchement sur d’autres réseaux / SàT.
-- etc.
Vous pensez à quoi pour l’hébergement ?
Pour le financement, faut tabler sur un budget annuel de combien ?
Pour l’hébergement je pense qu’on a deux pistes :
– demander aux hébergeurs assos qu’on connaît, j’en connais un sur Brest qui fêtait ses 20 ans ya pas longtemps, ça serait un beau cadeau pour eux ^^ (mais je suis certain que les #habitué⋅e⋅s_de_seenthis en connaissent d’autres)
– faire une cotizzz pour choper un ty vps avec un ssd pas cher (de 3 à 12 euros HT par mois suivant l’espace nécessaire)
Ensuite, on donne les clés de la machine aux personnes motivées pour aider, et zou ?
ça me semble sympathique cette idée de groupe... On attaque comment : une liste de diffusion (du style seenthis@rezo.net) ou...?
Moi je serai ravi de faire parti du groupe et de soutenir financièrement à hauteur de ce qui est nécessaire. C’est malheureusement le seul truc efficace que je peux faire compte tenu du fait que je suis absolument analphabète du point de vue code, technique et machine. Mais je pense que seenthis est un outil merveilleux, précieux, utile, avec un superbe potentiel pour y développer des idées, des projets. C’est aussi un laboratoire expérimental autant pour la forme que pour le fond, c’est un transmetteur de connaissance, de savoirs, un vrai lieu de partage, un des rares endroits sur la toile collaborative qui est presque « troll-free ». j’oublie des qualités... Mais je veux dire que je souhaite vivement soutenir avec ce que je pourrai faire.
C’est un peu la même chose de mon côté, administrer mon serveur ça va, mais Seenthis c’est autre chose. Par contre faire partie du groupe pour contribuer, apporter un soutien financier, écrire de la doc, ou autre chose, avec plaisir et impatience !
+1 pour la mailing-list
+1 pour la cotizz (@b_b tu penses à un truc du genre cloud hosting à la digital ocean ? Si c’est ça, je peux aider, si c’est un serveur dédié où tout faire à la mano, ouf, je serais dépassée).
On a monté l’association « AMIS » à quelques joueurs invétérés il y a quelques années. On cotise tous pour une machine... famélique... mais... l’idée est celle-là. Je gère la machine, un LAMP sur un KS OVH.
J’ai aussi une association qui ne vit pas plus que cela (je n’ai jamais pris la peine de lui créer un compte en banque...). Elle était supposée prendre en charge le serveur de Zoo-logique.org, le serveur de news... mais finalement, le serveur nécessaire à ce truc plus les sauvegardes, tout cela passe d’une façon transparente sur l’infra. financée par mes propres moyens...
Et donc, pour Seenthis, soit on alimente un compte Paypal sans se poser de questions sur « à qui appartient ce compte ? »... soit on monte une vraie association, avec toutes les lourdeurs que ça représente, et l’obligation donc, d’avoir un président, un trésorier, un secrétaire, une AG annuelle...
Pour la technique, je suggère une VM cloud chez OVH. Elles sont bien assez puissantes et permettent de monter en gamme à moindre coût.
Et pour l’installer, je peux aider/faire si nécessaire. La gérer, je peux aider/faire si nécessaire.
Moi je serais ravi de faire parti du groupe et de soutenir financièrement à hauteur de ce qui est nécessaire. C’est malheureusement le seul truc efficace que je peux faire compte tenu du fait que je suis absolument analphabète du point de vue code, technique et machine. Mais je pense que seenthis est un outil merveilleux, précieux, utile, avec un superbe potentiel pour y développer des idées, des projets. C’est aussi un laboratoire expérimental autant pour la forme que pour le fond, c’est un transmetteur de connaissance, de savoirs, un vrai lieu de partage, un des rares endroits sur la toile collaborative qui est presque « troll-free ». j’oublie des qualités... Mais je veux dire que je souhaite vivement soutenir avec ce que je pourrais faire. (Putain c’est hyper pratique le copié-collé)
1. Comment pourrais-je ne pas soutenir ce projet de pérennisation de ST ?
2. Comment pourrais-je soutenir ce projet de pérennisation de ST ?
;-)
Un bouton de dons pour les sous et une mailing list ou un git pour le développement ?
Tout est déjà sous Git et sur SVN de spip-zone + il y a déjà une mailing-list (qui date du début). :)
Ce qu’il manque c’est donc surtout analyser et choisir un nouvel hébergement + définir les modalités (sur la mailing list par ex) de comment sera géré l’argent, les choses à payer, etc.
De toutes les questions, celle de l’argent est certainement la plus facile à régler : il suffirait d’une poignée de donateurices/cotisantes pour payer les factures, si tant est que la solution retenue implique des factures à payer.
Les points plus difficiles sont à mon avis :
– la mobilisation de compétences et le travail technique ; la dynamique sur le github a été jusqu’ici assez molle, et pour ce qui est des développements sur le serveur, vous avez compris ma position.
– le pourquoi et comment du collectif ; ça c’est probablement le plus délicat. Ca touche à la gouvernance démocratique, à la recherche du consensus, à la responsabilité, à la possibilité de la censure, à l’ambition des objectifs qu’on peut avoir, etc.
Cette discussion va peut-être nécessiter du temps, auquel cas, puisqu’il semble qu’il y a déjà une dynamique sur le plan technique, il ne faudrait pas en faire un préalable.
Il faudrait donc pouvoir avancer en parallèle (sans pour autant donner « le pouvoir » à celleux qui auront pris des décisions techniques).
Sur ces bonnes paroles, je prends une semaine de vacances ?
PS : j’avais démonté la mailing-list (qui était devenue obsolète), mais @supergeante vient de la relancer.
Yep. Inscriptions ici : ►http://listes.rezo.net/mailman/listinfo/seenthis
Faudrait un ou deux modérateurs en plus de bibi, au cas où.
@philippe_de_jonckheere peux tu s’il te plait rajouter un « s » à « qualités » dans ton copié collé :) J’ai qu’à l’avenir je vais travailler mon orthographe !
J’ai lancé plusieurs fils (finances, techniques) sur la mailing-list donc gogo. C’est arbitraire, mais c’est pour démarrer.
@supergeante je n’ai (pour l’instant) rien reçu, pourtant je suis bien inscrit depuis 12h52.
Question bête : pourquoi une mailing liste ? pourquoi pas seenthis tout simplement ? avec des #seenthis_finance #seenthis_technique #seenthis_etcetc
Ya les tickets Github aussi, si tout le monde qui veut participer (y compris non-technique) s’y inscrivent.
Je sais qu’il y a des communautés qui l’utilisent comme liste de discussion, avec les notifications emails et la possibilité de répondre aux tickets directement en répondant à l’email dans son lecteur habituel. (Mais ça fait dépendre de Github alors que Seenthis non ; mais c’est plus clair, car on peut classer avec les labels, trier, résoudre, répondre par email ou par web, etc. Et en plus c’est déjà utilisé de toute façon.)
Oui, du même avis que @ben, Seenthis est l’endroit idéal pour parler de... Seenthis non ? Et puis ça aidera aussi chaque utilisateur à se sentir concerné plutôt que de renvoyer ça en arrière boutique.
Pour ce qui est du code, c’est tout de même plus pratique de travailler sur Git (Github en l’occurrence). Mais créer un compte du type @seenthis_code sur lequel on renverrai via RSS les commits / pull requests / issues, ça pourrait être bien aussi.
Comme vous le voulez c’était pour avancer :) la liste est censée fonctionner... @fil ?
Désolée de ne pas pouvoir contribuer financièrement maintenant (c’est à peu près tout ce que je peux faire), ma priorité est d’avoir les moyens de faire réparer le ballon d’eau chaude :) #longue_vie_à_seenthis
Si tu postes tu as un message ? @biggrizzly ? Mich rien nada...
Ps : @fil reçoit les mails :P
Je ne peux pas m’empêcher de trouver un peu d’ironie à vous avoir vus, les unes et les autres, merdouiller en public sur la création d’une liste de discussion, le tout depuis un médium tellement plus puissant, seenthis , qui lui fontionne parfaitement, en grande partie grâce aux soins des uns et des autres ? Désopilant. C’est dit en toute gentillesse très amusée.
comme @philippe_de_jonckheere, @homlett et @ben : pourquoi ne pas continuer sur seenthis ?
Hello, si ces discussions se passent ici, je propose de créer un compte @seenthis_hebergement ou que sais-je et que ce compte soit lié éventuellement à la mailing-liste. On discuterait alors de ces questions avec ce compte, avec les hashtags qui vont bien... L’idée est simplement que l’on puisse gérer notre suivi avec un peu de finesse : s’abonner à ce compte ou non, suivre des hashtags ou non, chercher son historique ou non... Et pouvoir discuter des trucs pas en public, ça peut parfois être facilitant aussi. Du coup je laisserais malgré tout la mailing-liste ouverte de maniere autonome du compte.
Et/ou aussi faire un compte spécial comme @7h36 qui ferait un récapitulatif hebdomadaire des fils créés contenant le tag qu’on aurait choisi pour ces discussions, ou un truc dans le genre ?
Le tout est de se mettre d’accord sur des conventions qui permettent à chacun de s’y retrouver et de faire des automatismes vers la mailing-list.
Donc, maintenant que tout marche, on arrête de discuter ?
– hébergement => vers quoi on irait ? Qui veut mettre la main à la pate ? cf. #seenthis_hebergement
– finances => paypal ? cf. #seenthis_finances
Je cause où vous voulez. Mais promis, y-a des choses que je ne dirai pas ici.
Je copie-colle un bout d’un de mes messages :
Pour l’hébergement...
On a les pré-requis techniques. Parfait. Mais... Quels sont les éléments de volumétries diverses ? Nombre de visites journalières, nombre de hits sur l’application par jour, espace disque nécessaire, taille de la base de données MySQL, nombre de requêtes quotidiennes sur MySQL, Taille des données gérées par Sphynx (que je ne connais pas, mais j’imagine qu’il a un index et qu’il doit peser la taille de la base MySQL ?)
C’est tout de même un point important au moment de choisir une infrastructure technique.
Et puis, quel niveau de personnalisation des logiciels ? Peut-on installer ce site sur une Debian nue, avec une recette de cuisine de moins de quelques dizaines d’opérations successives ?
Et si on prend un hébergement, est-ce que c’est aussi pour préparer les évolutions futures et disposer d’un espace de prod’ et d’un espace de pré-prod ? voire même d’un espace de test ?
On s’amuse à monter le site sur docker ?
etc.
cf. ▻http://seenthis.net/messages/421545 - on attends donc des infos.
Là, j’ai un peu de temps, vu qu’il y a des motivés, est-ce qu’on ouvrirait pas déjà un paypal ou autre pour mettre des sous de côté en vue de payer ce fameux hébergement quand il sera défini ? #seenthis_finances
@Fil Mais, finalement, une structure a été créée ? Un collectif est défini ? Je n’ai pas trouvé ça dans ►https://seenthis.net/messages/505099
@biggrizzly vu que tu as accès à la machine, ça te dirait de nous rejoindre dans la team techs sur le repo github associé au nouvel hébergement ?
coucou ! je fais remonter vu que c’est d’actu ! j’ai cherché une conversation plus récente qui en parle mais pas trouvé ...
Ah ben j’avais pas vu les derniers commentaires... Je me suis inscrit sur Github...
@biggrizzly je ne te retrouve pas, ping moi pour que je t’ajoute à la team :)
ps : je suis ici ►https://github.com/brunob
Et maintenant... #seenthis_finances
Un schéma simple qui pourrait fonctionner ici (.be)
– compte bancaire (en ligne ?) gratuit avec 3 ou 4 mandataires (association de fait « les donations à seenthis »)
– on appelle les membres à verser sur ce compte selon leur volonté
– virement automatisé mensuel vers le compte de l’hébergement, soit du montant nécessaire soit de la totalité (remise à « 0 » mensuelle du compte)
– décompte anonymisé mensuel/trimestriel reporté ici
CloudFlare : Le syndrôme Akismet ? - sebsauvage.net - Les trucs qui m’énervent -
►http://sebsauvage.net/rhaa/index.php?2012/01/23/13/42/15-cloudflare-le-syndrome-akismet-
CloudFlare est mis en place à l’initiative des webmasters. Il se place entre les internautes et votre site web. Il agit comme un reverse-proxy : Toute #requête HTTP destinée à votre site passe d’abord par les serveurs CloudFlare qui l’analysent et éventuellement la bloquent. Le service offert par CloudFlare est trop tentant : Protection contre le spam, les DDOS, statistiques, CDN, cache... le tout dans un service gratuit. Tellement tentant qu’un quart des internautes passent sans le savoir par CloudFlare (Korben, PC-Inpact, Zataz...). Si CloudFlare s’écroule ce sont des centaines de milliers de sites qui vont devenir tout à coup inaccessibles. Ouais, vive la centralisation. On remplace le risque (local) qu’un site s’écroule par un risque global, CloudFlare devenant une cible de plus en plus intéressante à mesure qu’elle grossit. Je ne suis pas certain que ça soit mieux pour internet.
[...]
Malgré l’excellence technique de #CloudFlare, je ne suis pas prêt à troquer ma liberté d’expression et la vie privée de mes visiteurs contre une commodité. Oui mon site tombera peut-être plus souvent que ceux utilisant CloudFlare, mais j’assume. Question de choix. Question de confiance. Je suis peut-être un peu jusqu’au-boutiste, mais comme Timo (Le Hollandais Volant), Mitsukarenai (Fansub-streaming) ou Hoper, j’ai plutôt envie de réduire les dépendances.
Quand on est derrière #Varnish, PHP ne voit plus les adresse IP des visiteurs dans REMOTE_ADDR (il ne voit plus que l’IP du serveur qui héberge Varnish, c’est-à-dire lui-même si Apache et Varnish sont sur la même machine).
Modif : suite aux commentaires de
, version différente dans le forum.Ce que j’ai trouvé :
Ajouter l’IP en entête X-Forwarded-For dans sub vcl_recv (pas réussi dans vcl_fetch). Perso, il me suffit de le faire systématiquement quand je détecte une requête en POST, puisque les formulaires que j’ai besoin de tracer sont dans cette méthode :
►http://pastebin.com/KzyNz7vJ
Dans PHP, je récupère l’IP ainsi :
►http://pastebin.com/P6qEUarv
Si quelqu’un a mieux... (moi je bidouille, avec ça, hein).
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 ?
Merci @fil. Voici donc ma nouvelle config :
– J’installe mod_rpaf (ici, Debian) :
– 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
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).
À noter que les en-têtes X-... ont été supprimés. Pour cette fonction, il faut désormais utiliser l’en-tête Forwarded : ▻http://www.bortzmeyer.org/7239.html Pour Varnish, voir ▻https://www.varnish-cache.org/docs/2.1/faq/http.html
Upgrading from #Varnish 2.1 to 3.0
►https://www.varnish-cache.org/docs/trunk/installation/upgrade.html
Upgrading from Varnish 2.1 to 3.0
This is a compilation of items you need to pay attention to when upgrading from Varnish 2.1 to 3.0
Changes to VCL
In most cases you need to update your VCL since there has been some changes to the syntax.
Using #Varnish So News Doesn’t Break Your Server - NYTimes.com
►http://open.blogs.nytimes.com/2010/09/15/using-varnish-so-news-doesnt-break-your-server
This mix-up resulted in a sudden burst of more than 300 requests per second to our machines — and we saw this burst all too clearly on our screens, because every home page load was hitting our machines (thankfully, it was a Friday afternoon and not election night). Three months earlier, I would have been swearing profusely at this point, trying to spin up new servers in time to avoid watching all my application servers groan and die. But that day I watched as all of the application servers remained unperturbed. The difference? Varnish.
Varnish n’a pas peur de la montée en charge
►http://blog.nicolargo.com/2011/04/varnish-na-pas-peur-de-la-montee-en-charge.html
m’a permis de re-découvrir le site Load Impact qui permet de tester la montée en charge de votre service Web en simulant un nombre croissant de connexion. J’ai profité de cet outil sympa pour tester les performances de mon blog sans et avec le proxy cache Varnish (dont j’avais détaillé l’installation dans ce billet).
►http://blog.nicolargo.com/2010/10/booster-votre-blog-wordpress-avec-varnish.html
[Bon, je vais essayer d’utiliser SeenThis pour garder trace des URL utiles.]
Ressources sur la gestion de sites #Apache sous forte charge (plutôt orientées vers l’administrateur du petit site pas riche).
►http://stackoverflow.com/questions/450606/limit-number-of-concurrent-connections-in-apache2 (plutôt sommaire, comme conseils)
►http://dominia.org/djao/limitipconn2.html (intéressant module Apache)
J’ai fait un article un peu plus détaillé ►http://www.bortzmeyer.org/limit-apache.html
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.
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
un article pas dégueu sur des stratégies d’invalidation
▻http://www.smashingmagazine.com/2014/04/23/cache-invalidation-strategies-with-varnish-cache
mais bon la méthode du plugin #SPIP est déjà vraiment bien
Depuis la semaine dernière, déménagement de Flip-Zone sur un nouveau serveur. La vitesse de consultation devient spectaculaire.
Cela s’est traduit immédiatement par un nombre de pages vues en très nette augmentation. Quasiment 50% sur Flip-Zone et près du double sur Lebanese-Fashion.
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
Je viens de poster un nouveau #plugin #SPIP sur #spip-zone : Microcache
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/plugins_seenthis/microcache
– à la base, c’est la fonction de @fil pour ►http://rezo.net,
– mais comme le nom du #microcache est facilement accessible, elle est complétée par une fonction de suppression du cache.
Sur Seenthis, c’est le système qui me permet de travailler avec des squelettes SPIP, tout en ayant à la fois :
– un système de cache statique et persistant,
– des mises à jour en temps réel (il me suffit d’effacer les fichiers microcache qui vont bien quand on poste un message).
Ah oui, ça s’utilise ainsi :
[(#ID_AUTEUR|microcache{inc/truc_auteur})]
où inc/truc_auteur.html est un squelette tout à fait classique. La valeur de l’#ID_AUTEUR est à récupérer, dans ce squelette, avec la variable #ENV{id}.
Pour effacer ce microcache, a priori ça se fait directement dans du PHP (à la validation d’un formulaire, certainement) :
effacer_microcache($id_auteur, « inc/truc_auteur ») ;
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).
Quelqu’un a essayé ça?
►https://github.com/timwhitlock/php-varnish
#Varnish, interface depuis PHP.
Sinon, tu as déjà réussi à utiliser les fonctionnalités ESI ?
►http://www.varnish-cache.org/trac/wiki/ESIfeatures
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
The #Varnish Moral #License
►http://phk.freebsd.dk/VML
Varnish Moral License (almost) pays for half-time developer.
The Varnish Moral License, is a voluntary license payment, directly to the author of Varnish, which helps pay for the development of Varnish.
Buying a Varnish Moral License is 100% voluntary, if you do not make money from your website, there is no reason why you should pay for a license to use Varnish on it.
If however, Varnish helps your website generate a profit, you should consider getting a Varnish Moral Licence.
In all cases, it is entirely up to you (and your morals) if you should get a license or not.
Suite à la piqure de rappel de @monolecte,
►http://seenthis.net/messages/9627
la détection de la langue du visiteur (utilisée pour l’instant uniquement pour le lien de traduction) se fait côté serveur pour les visiteurs identifiés. PHP accède à une valeur à laquelle javascript n’accède pas sous Firefox (penser à insulter Nitot :-)).
Je ne peux pas le faire facilement pour tous les visiteurs, parce que je suis planqué derrière #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.
Attention : déménagement. J’installe Seenthis sur une nouvelle machine, il risque d’y avoir des bizarreries ce soir (jeudi).
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.
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.
Chouette bug dans l’affichage des dates relatives des billets : la « date_now » était passée dans un bout de microcache, et n’était donc plus dynamique.
Je passe ce morceau en affichage_final, et basta. (Sauf qu’évidemment ça va déconner avec #Varnish, mais on ne va pas pleurer non plus.)
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
Si, ce serait mieux.
#ne_me_demandez_pas_comment_je_suis_arrive_ici_j_en_sais_rien ^^
ESI Language Specification 1.0
►http://www.w3.org/TR/esi-lang
Edge Side Includes (ESI) is an XML-based markup language that provides a means to assemble resources in HTTP clients. Unlike other in-markup languages, ESI is designed to leverage client tools like caches to improve end-user perceived performance, reduce processing overhead on the origin server, and enhanced availability. ESI allows for dynamic content assembly at the edge of the network, whether it is in a Content Delivery Network, end-user’s browser, or in a “Reverse Proxy” right next to the origin server.
À essayer avec #Varnish.
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.
Je cherche comment réduire le ttl de #varnish pour un domaine donné. Le serveur qui héberge ►http://www.flip-zone.com a un ttl de 3600. J’ai besoin de le régler à beaucoup moins pour #seenthis.
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.