PHP Sessions Can Hurt Your WordPress Performance

CMS WordPress
, ,
21

Sincer nu te inteleg.
Ai inceput interesant PHP Sessions Can Hurt Your WordPress Performance speram sa aud ceva crucial despre Varnish ESI in continuare.
Dar tot ce faci pare o logica fortata de a ajunge into-o situatie de exceptie care sa accepte argumentul tau.
Ok, fara Varnish in fata se va strica html-ul. Dar merg pe aceasi logica, ce faci cand nu mai ai serverul web in fata? Ce faci fara DB?
Ai facut vreo aplicatie care sa tina milioane de useri?
Sune-ne si noua ce ai facut, ca sa tina atatia useri simultan pe site.

Este al doilea topic din care simt ca imi iei tot cheful de a mai citi si posta ceva, incercand sa fortezi niste concluzii. A se vedea si PHP and the dollar sign

22

Ideea este ca promovezi bad practices (da stiu, imi place sa folosesc expresia asta) - argumente:

  • din 2001 nu exista un accepted standard pt. ESI
  • iti leaga aplicatia de Varnish cand de fapt solutia clasica este: just use xhr for the auth. users
  • in felul acesta nu iti legi aplicatie de un tool extern - e ca si cum my web app ar merge doar cu nginx si nu cu apache

Nu vreau sa-ti stric cheful - insa cand vad ceva care pare out of order voi raspunde pt. ca apoi cineva o sa-ti urmeze sfatul.

23

Limitarea ar fi mai degraba pe partea de filedescriptori. Pentru I/O nu cred ca se pune problema, din doua motive:

  1. Sistemele de operare folosesc agresiv cache-ul pe filesystem, deci rareori va atinge dispozitivul de stocare (poate doar flush-ul de la scriere, dar ala e asincron)
  2. Sesiunea fiind ceva temporar (am impresia ca nu se poate schimba timpul de expirare, cookie-ul se sterge cand se inchide browserul) pot sa setezi php-uri sa scrie sesiunile in tmpfs.

Si oricum scrierea direct pe HDD e mult mai eficienta decat scrierea in DB. Singura problema cu mecanismul asta apare la sistemele distribuite si atunci memcache ar fi o varianta mult mai buna.

1 Like