Pornind de la un comentariu PHP Sessions Can Hurt Your WordPress Performance as vrea sa va intreb ce experiente ati avut cu ESI caching
Dealungul timpului am tot avut tentative sa folosesc asa ceva insa mereu am gasit alte variante
“There are only two hard things in computer science: cache invalidation and naming things.”
— Phil Karlton
relevant (more or less):
Eu am pornit de la intrebarea: ce sens are Varnish fata de nginx/apache daca you do all the cache config in your own app.
Pentru ca este mult mai simplu sa invalidezi stuff like Russian doll caching din your own app decat externally care practic tot trebuie legat cumva de your app.
Eu am facut de 2 ori MVP pentru ESI cu Varnish si Symfony la munca. Nu a fost nici greu, nici usor, insa de fiecare data ceea ce implementam eu a ajuns pe lista proiectelor oprite la taierile de buget si nu am finalizat. Mi-as fi dorit f mult sa apuc sa masor cu traficul pe care il aveam pe proiectul respectiv, insa nu a fost sa fie.
Sunt curioasa daca putem detalia.
Am invatat in decursul timpului ca solutia tehnica aleasa are legatura si cu echipa care o propune/implementeaza. Daca DevOps este cel care face research, se va ajunge la o solutie care imbraca aplicatia, si nu atinge codul. Daca echipa care implementeaza este cea care propune o solutie de caching, aceasta ar putea atinge codul aplicatiei.
Eu nu spun ca e bine sau rau intr-unul din moduri, doar ca depinde de f multi factori. Si eu as fi tentata sa aleg o solutie care “murdareste” codul aplicatiei cu notiuni de caching daca ar face sens din toate celelalte puncte de vedere.
De obicei am folosit memcached/redis, tinand in cache varianta html pentru respectivele widget-uri + un versionid pentru content pentru invalidare. Chestia asta a funcționat acolo unde schema de invalidare a contentului era relativ simpla.
Chiar sunt curios cum a fost implementata chestia asta cu id-ul pentru invalidare, ca imi da impresia ca tot trebuie sa interoghezi db-ul pentru a afla id-ul.
Eu cand am avut nevoie de memcache am aplicat o chestie foarte simpla: cand in backend se schimba ceva, la salvare se stergea si intrarea din memcache.
True. De multe ori sa tragi un id (campul updated_at poate fi folosit ca version id) nu costa mult
Da, stergerea cheilor de cache e o solutie foarte buna, pe care o folosesc si eu in anumite situatii, fie dupa hash fie dupa tag (redis iti permite eficient acest lucru din urma)
Thx de reply. Si eu tot pe varianta asta am mers la inceput, apoi am dezvoltat ideea de silos si am ales alte modalitati de distribuire a continutului.
Legat de caching mai avansat cu chei, RoR foloseste Russian-doll strategy.
Am vrut să folosesc Varnish că să ma ajute la un proiect preluant pentru mentenantă care avea probleme cu spike-uri de trafic. Până la urmă am mers pe fastcgi_cache din nginx pentru că deja aveam stack-ul instalat (nginx + php-fpm). și era mai puțină bataie de cap. Experiența mea confirmă articolul postat de @dakull mai sus, vă recomand să îl ciți dacă nu ați făcut-o deja.
Argumentul suprem pentru care am renunțat la Varnish a fost că trebuie sa gestionez conexiunile SSL tot in nginx, deci practic as fi avut un sandwich nginx - varnish - nginx - php-fpm (443 - 80 - 8080 - socket).
Varnish fară ESI este echivalent (o ideie mai încet) decat nginx + proxy/fastcgi_cache, ambele fac full page cache deci trebuie să fii atent dacă ai utilizatori sau conținut personalizat.
Una peste alta eu vad Varnish ca pe un tool super-specializat pe care îl folosești în condiții specifice și doar dacă știi (sau ai un sysadmin care știe) șă profite de atuurile sale: VCL (reguli complexe pentru gestionarea cache-ului pe care nu le ai într-un setup de nginx) și ESI.
ESI mi e departe de a fi ideal dar cel puțin într-o aplicație Symfony obiții mai repede un setup Varnish + ESI, decât ai implementa Russian-doll caching, cu condiția să fii familiarizat deja cu Varnish.
Dacă ai timp in-app caching cu redis/mecache/apcu în funcție de nevoii pe blocuri mi se pare mult mai robust, mai usor de testat, etc.
PS: de ce “russian-doll” și nu Matryoshka caching? 
Eu unul nu am problema per se cu Varnish ci cu ESI, evident ca Varnish isi are sensul in anumite cazuri specifice.
Insa ESI nici macar nu trece de HTML5 validation - pare some kind of XML-era relic. Insusi exemplu din doc. de la Varnish says it all:
<HTML>
<BODY>
The time is: <esi:include src="/cgi-bin/date.cgi"/>
at this very moment.
</BODY>
</HTML>
Who in their right mind still writes HTML like that?
are we web devs. or what?
