Pentru ca eu pot, si-mi hostez singur blogul, am invatat de-a lungul timpului ce trebuie sa faci ca sa ai un blog cu trafic, dar mai ales ce trebuie sa faci tehnic ca blogul sa sustina orice peak de vizitatori. Una din solutii este un plugin de cache. Dar care din ele?
Ce face un plugin de cache?
Ca sa se afiseze o pagina de web pe wordpress, trebuie sa se urmeze cativa pasi. Utilizatorul cere pagina de web. Serverul vede cererea si intreaba baza de date daca are asa ceva. Baza de date ii raspunde solicitarii cu elementele din pagina respectiva. Wordpress-ul vede ce ii trimite baza de date, ia datele alea, le compileaza si le trimite serverului web spunandu-i si cum sa le afiseze in functie de tema, poze, elemente etc.
Pentru ca operatiunea asta este de obicei intensiva pe baza de date, existand pentru un singur articol o groaza de intrebari in baza de date, dar si o groaza de raspunsuri, totul poate fi intarziat. Si de aici ideea ca un site se misca greu.
Pluginul de cache vine si strange informatiile astea intr-un loc de pe server, urmand ca sa raspunda el in locul bazei de date sau eliminand din interbarile astea care pot fi si in numar de 60 – 70 pentru un singur articol. Asa incat pentru primul utilizator care citeste un articol se executa tot sirul de intrebari in baza de date, compilari de date si randari de pagina, iar pentru ceilalti se serveste deja pagina compilata si presalvata de catre pluginul de cache.
Cum alegi un plugin de cache?
Teoretic alesul unui plugin de cache nu e greu. Te duci la pluginuri, dai sa caute cache, iei si instalezi. Practic, nu e asa de simplu. De cele mai multe ori pluginurile de cache au o sumedenie de setari si o groaza de optiuni care nu sunt clare pentru toata lumea. Cele mai la moda sunt pluginurile care iti salveaza pagina asa cum o vezi tu, pe disk, intr-un loc pe server. Si astfel se elibereaza baza de date de stress, dar si serverul de compilari. In schimb se aglomereaza hard-disk-ul de pe server cu cereri, in functie de traficul avut. Pentru un trafic mic / modest, un plugin de cache de tipul asta este potrivit pentru blog, imbunatateste cu vreo 10% performantele blogului decat fara cache.
Cache baza de date? Cache de pagini?
Una din cele mai interesante intrebari este ce plugin de cache sa folosesc. Unul care optimizeaza doar baza de date? Unul care salveaza deja paginile? Raspunsul ar fi unul singur: ceva care stie sa le faca cu succes pe toate. Si asta din doua motive, o data facut cache-ul pe baza de date se elibereaza serverul de cererile bazei de date, e ok, e bine. Dar poate creste traficul, asa incat vor exista mai multe cereri in Apache (iis, nginx, lighthttpd, etc), iar serverul web se va stresa incercand sa serveasca aceasta, facand cate o cerere independenta pentru fiecare obiect in pagina.
Spre exemplu daca aveti o pagina de blog cu 80 de poze, 5 javascripturi, 2 stiluri css si ceva comentarii ati avea fara cache, vreo 87 de cereri catre serverul web. La acestea se adauga cererile cu elementele grafice ale paginii respective, pe langa care se pun cererile din baza de date care pot fi peste 150, pentru ca baza de date cam raspunde de orice element al paginii (poze, text, comentarii, stil, numele blogului, etc). Si de aici toate cererile astea sunt procesate de catre procesor (stiti voi traducerea aia din 1010101010100011 in ce vedeti aici).
Da, cache-ul bazei de date optimizeaza, dar ce faci cu restul?
Best practice W3 Total Cache
Nu foarte multe servicii de hosting ofera optiunile pe care pluginul de cache W3 Total Cache le are. Asa incat chiar daca APC, eaccelerator, xcache si wincache sunt bune, eu prefer sa folosesc memcache. Pentru ca memoria ram are rata de transfer mai mare si e multa, mai nou si ieftina.
Am active in felul urmator: Page cache in memcached, minify (setarile auto si default, altfel imi dau eroare niste javascripturi) in memcached, database cache in memcached, object cache in memcached, browser cache, CDN.
Astfel cererile nu le serveste serverul apache intreband diskul de fiecare data, incalzindu-l si stresandu-l (adica inca suntem la tehnologia cu platane si ac, pana la urma se strica), ci face asta de cateva ori mai repede din memoria ram.
In plus de asta nu exista un singur server web. Pana si google recomanda ca fisierele mici, de genul CSS, javascript, poze sa fie servite din alta parte. Aici intra in actiune CDN-ul (content delivery network) care preia din sutele de cereri de care vorbeam mai sus si foloseste un alt server pentru a le servi. In schimb daca serverul ala nu e apache, asta se intampla si mai rapid. De exemplu nginx.
Si toate astea pe un server virtual. Aparent un server virtual se misca mai bine in productie decat un server fizic.
Probleme W3 Cache
In principiu ca orice produs free, suportul e pe bani. Asa e si la W3 total cache, daca nu va descurcati si nu stiti pe cineva care sa se priceapa foarte bine, poate ar fi o idee sa va uitati la preturile de la suport. In schimb pe mine ma dispera ca ei nu prea accepta alt CDN decat cele propuse de ei acolo. Adica daca vii cu unul custom, ai oarece sanse sa iti strici definitiv permalinkurile catre poze / fisiere. In schimb nici la update nu-mi pastreaza setarile de CDN.
Recomandarea ar fi ca la un update, o data faceti backup, iar altfel sa testati daca aveti cand si cum pe un blog de test pluginul asta.
Bun, intrebari?
Comentariile specialistilor care se afla in treaba nu vor aparea.