Nu îmi aduc aminte să fi folosit sesiuni în WP, dar nici nu aș putea spune că eram conștient de neajunsuri.
So if you’re calling session_start() early on every single request, best case scenario is your caching solution will simply ignore and never cache these requests. Worst case — it will cache the requests individually, meaning if 1000 visitors opened your home page, you now have 1000 different cached copies of the same page
Depinde de context - insa presupun ca prezenta unui session key implica posibilitatea unei pagini specifice pt. un utilizator deci one unique cache key per session.
Cache-ul presupune că servești același conținut tuturor clienților.
Eh, în momentul în care activezi sesiunile, tu îi spui serverului că e posibil să trimiți ceva specific spre vizitatorul care încearcă să acceseze pagina, ergo nu mai poți servi ceva cached.
Și ajungi într-una din cele două situații descrise în articol:
nu mai servești pagini cached;
servești unui utilizator paginile cached ale unui altui utilizator.
Parcă wp-super-cache făcea o chestie foarte „mișto” (deși nu știu dacă era doar o problemă de config sau bug): servea paginile cached, astfel încât vizitatorii vedeau datele ultimului comentator (nume, mail, url).
Conteaza cum implementezi cache-ul si mai ales ce folosesti pt cache. In primul articol mi se pare o implementare proasta a cache-ului.
Nu folosesc WP si nu stiu plugin-urile specifice, dar ai diferite optiuni pentru a avea cache si sesiuni.
Daca folosesti un http accelerator cum ar fi Varnish, acesta are ESI care te lasa practic sa spargi blocurile dinamice in pagina si sa le serveasca serverul web.
Daca iti faci propriul sistem de cache (cum inteleg ca este in articol), poti sa cache-uiesti tot pe bloc-uri (urmezi o implementare asemanatoare cu Varnish ESI), sau faci un request ajax pentru a prelua informatiile dinamice (care se presupune ca este mai rapid decat daca ai lua toata pagina).
Sesiuni in fisiere sau DB? Cand ai Memcache sau Redis?
Chiar folosesti asa ceva? practic generezi o hard dependency between varnish and your web-app. Nici nu ma mir ca din 2001 de cand a fost submitted W3C inca nu l-a acceptat.
Articlul și-a pierdut credibilitatea când am ajuns la:
WordPress Does Not Use PHP Sessions
It’s worth noting that WordPress Core does not use native PHP sessions. Instead, it heavily relies on cookies for authentication, and stores any additional information about an authenticated session in the database.
Pai token-ul de sesiune stă tot într-un cookie (la fel ca și atentificarea), iar datele din sesiune sunt stocate implicit în fisiere pe disc, dar nu te împiedică nimeni să le ții tot tot in baza de date. Mai jos mentionează și ei că poți stoca sesiunile în baza de date.
Click bait title, contrazis de concluziile pe care le-au scris chiar ei la finalul articolului (accentul e pus de mine):
Always keep an eye out for all the cookies being set by your website, and don’t forget that JavaScript can set cookies that hurt your cachability too.
meh, ce explica ei acolo e sesiune 100%. nici nu m-am mai obosit cu aberatia aia. intrebarea mea era cine dracu si-a inchipuit ca-i o idee buna sa faci cache la o pagina in functie de cookieuri (in fond, sesiunea sta pe server, in browser ai un cookie de identificare)?
Dacă aplicația folosețe cookie-uri trebuie să ții cont de ele, că să nu afișezi conținut destinat unui utilizator altui utilizator. Un exemplu concret pe Wordpress: tu intri pe un blog, lași un comentariu (completezi nume, email, care sunt stocate în cookie), intru eu și când vreau să comentez și eu mă trezesc că în formular sunt trecute datele tale, ceea ce nu e deloc bine. Cum a zis si @iamntz mai sus legat de wp-super-cache.
Articolul bate câmpii despre nimic. “PHP session” e un mecanism care iti permite sa stochezi cateva crâmpee de date pe HDD, folosind cookie drept cheie. Un fel de array asociativ persistent. Ce legatura are asta cu performanta, doar autorul ştie
@dakull<esi:include ... > este un placeholder, nu inteleg cu ce te deranjeaza?
@iamntz Daca dai link-uri la articole, fara ceva personal, mai greu sa le citeasca cineva… Deja primul articol a generat cateva interpretari si fiecare se leaga de ce vrea si stie.
@serghei Articolul bate campii si nu. Ideea este ca in php default, sesiunea este salvata in fisiere dar poti schimba. Daca folosesti fiserele, atunci o sa folosesti HDD-ul (SSD-ul) mai mult decat ar fi nevoie. Chiar daca este extrem de rapid (SSD), poti sa ajungi sa nu mai ai FD pentru alte procese. Daca folosesti DB, ajungi cam in aceasi situatie, doar ca atunci o sa blochezi DB-ul.
