Redis Cache vs NGINX FastCGI Cache
Memorarea în cache este coloana vertebrală a vitezei și performanței site-ului. Este esențial pentru succesul site-ului dvs. WordPress. Chiar dacă site-ul dvs. este găzduit pe un server puternic, tot poate cădea la un acces cu crawlere dacă nu aveți nicio memorie cache activată. Servirea site-urilor pentru zeci de mii de utilizatori pe zi este posibilă numai datorită tehnicilor inteligente de stocare în cache.
În acest articol, vom pune două soluții distincte de stocare în cache a paginilor WordPress, Redis Cache vs NGINX FastCGI Cache. În timp ce NGINX FastCGI Cache este un veteran de stocare în cache a paginilor, Redis Full-Page Cache este relativ obscur.
Cine va ieși în primul și cine se va prăbuși sub sarcină? După cum veți afla în curând, ambii au avantajele și dezavantajele lor, dar există un singur câștigător.
Memorarea în Cache WordPress 101
WordPress necesită multe părți mobile pentru a funcționa. De fiecare dată când un utilizator solicită o pagină de pe un site WordPress, cererea este mai întâi analizată de server. Dacă serverul nu poate servi cu ușurință pagina solicitată, va procesa scripturile PHP relevante și va asambla pagina în mod dinamic. Uneori, acest lucru implică și interogarea bazei de date pentru a aduna date suplimentare.
Ca regulă generală, cu cât cererea trebuie să parcurgă mai mult, cu atât răspunsul serverului este mai lent. Dacă există mulți utilizatori concurenți, serverul se poate bloca încercând să proceseze toate solicitările paralele.
Memorarea în cache ajută la accelerarea răspunsului serverului prin stocarea și livrarea cererilor procesate anterior. Un server poate implementa multe straturi de cache pentru a stoca tipuri distincte de date.
Pentru aplicațiile PHP și bazate pe baze de date, cum ar fi WordPress, există patru tipuri majore de soluții de stocare în cache pe server: Object Caching, Page Caching, Opcode Caching, și CDN Caching. Puteți citi mai multe despre toate acestea în articolul nostru despre object caching.
Acest articol se concentrează pe compararea soluțiilor de stocare în cache a paginilor, dar vă sugerez să vă familiarizați și cu elementele de bază ale stocării în cache a obiectelor.
Configurarea Site-ului de Testare și a Serverului
S-a folosit un droplet standard de 10 USD de la DigitalOcean pentru a efectua testele. Cu o memorie decentă și resurse de calcul, a fost un server perfect pentru a testa site-ul WordPress. Configurația droplet include 2 GB RAM, 1 CPU, 50 GB SSD stocare și 2 TB transfer.
Au instalat site-ul WordPress de testare pe LEMP bazată pe Debian (Linux, NGINX, MariaDB și PHP 7.3). Pentru a sublinia site-ul de testare, l-au personalizat pentru a include un amestec decent de elemente statice și dinamice folosind WooCommerce și Elementor.
Au testat site-ul de bază cu instrumentul de testare a vitezei GTMetrix. După cum puteți vedea din raportul său de testare, nu este încă optimizat pentru performanță.
Testarea de Stres a Site-ului de Bază Fără Cache Activat
Au folosi un instrument gratuit de testare a performanței numit loader.io pentru a testa site-ul. Versiunea lor gratuită vă permite să testați două adrese URL ale oricărui site web cu până la 10.000 de clienți concurenți timp de un minut. Este mai mult decât suficient pentru cazul lor de utilizare.
Dacă vă întrebați despre numele domeniului, acesta a fost un domeniu personal neutilizat. Este esențial să aveți site-ul găzduit pe un domeniu real pentru a instala un certificat SSL de la o autoritate eligibilă, cum ar fi Let’s Encrypt. Cu un certificat SSL instalat, site-ul trebuie să efectueze un HTTPS handshake pentru fiecare cerere unică a clientului. Acest lucru imită mai bine utilizarea în lumea reală în timpul testului de stres.
Puteți verifica parametrii de testare în caseta portocalie din partea stângă. Rețineți parametrul de testare de la 0 la 200 de clienți pe 1 min. Aceasta înseamnă că loader.io va testa site-ul web prin creșterea lentă a numărului de clienți activi de la 0 la 100 pe o perioadă de 1 minut.
În graficul prezentat, linia verde reprezintă numărul de clienți concurenți, iar linia albastră reprezintă timpul mediu de răspuns al serverului. Puteți vedea că timpul de răspuns crește pe măsură ce crește numărul de clienți.
Loader.io a anulat testul după 36 de secunde, deoarece mai mult de 50% dintre solicitări nu au avut succes (un timeout sau un răspuns de eroare HTTP 400/500). De asemenea, timpul mediu de răspuns de 17,33 secunde nu este de bun augur nici pentru experiența utilizatorului.
Verificarea filei Detalii vă va oferi o mai bună înțelegere a momentului în care pornesc timeout-urile serverului. Puteți vedea că începe de la 25 de secunde.
Au rulat din nou testul, de data aceasta limitând numărul de clienți concurenți la 100. Site-ul de bază s-a străduit să funcționeze chiar și sub această sarcină minimă.
Testul a rulat timp de un minut întreg de data aceasta, dar timpul mediu de răspuns al serverului este încă inacceptabil. Fiecare utilizator activ stresează mai mult serverul, ceea ce îl face să răspundă încet la toți ceilalți utilizatori. Timeout-urile serverului încă persistă.
Din graficul de mai sus veți observa că timeout-urile serverului încep să apară la marcajul de 38 de secunde din test.
Acum aveți o idee corectă despre cum funcționează site-ul de bază atunci când există 100 și 200 de clienți activi. Este timpul să efectuați aceleași teste cu Redis Page Cache sau NGINX FastCGI Cache activate pe server.
Ce este Redis Full-Page Cache?
Redis (Remote Dictionary Server) este un depozit de date extrem de rapid în memorie pentru utilizare ca bază de date, cache, proxy și multe altele.
Deoarece Redis își stochează datele în memorie, spre deosebire de bazele de date tradiționale care stochează date pe discuri fizice sau SSD-uri, Redis poate căuta și furniza date foarte rapid.
Deoarece stocarea în memorie este mai costisitoare de scalat pe un server web, Redis este ideal pentru stocarea în cache a fișierelor mai mici, cum ar fi rezultatele interogărilor bazei de date și sesiunile persistente. Astfel, Redis este de obicei folosit pentru a activa stocarea în cache a obiectelor și nu stocarea în cache a paginilor.
Oamenii deștepți de la Pressjitsu au adaptat caracteristicile unice ale serverului Redis și au implementat o soluție de stocare în cache a paginilor susținută de Redis pentru WordPress. Utilizează directivele Redis maxmemory #mb și maxmemory-policy allkeys-lru pentru a se asigura că serverul își folosește eficient memoria volatilă limitată, eliminând paginile mai vechi din cache pentru a face loc celor noi.
Redis Page Cache stochează și servește memoria cache de pagină completă din magazin în memorie, la fel ca modul în care funcționează Redis Object Cache. Din punct de vedere tehnic, acest lucru ar trebui să facă din acesta un cache extrem de rapid.
Cum să Activați Redis Page Cache
Documentația pentru a activa pluginul Redis Page Cache este puțin inconsecventă. După câteva încercări și erori, l-au făcut să funcționeze pe configurarea lor. Iată pașii pe care i-au urmat:
1.Înainte de a instala pluginul, asigurați-vă că aveți serverul Redis instalat și rulează pe serverul dvs. web. Dacă utilizați Debian/Ubuntu, iată comanda pentru a-l instala prin terminal:
sudo apt-get install redis-server
Vă recomand să urmați tutorialul Digital Ocean despre instalarea și securizarea Redis pe distribuția dvs. Linux. Dacă aveți orice altă variantă de Linux, acestea au tutoriale separate care se adresează aproape tuturor distribuțiilor Linux majore.
2.După ce ați instalat și configurat Redis pe serverul dvs. web, trebuie să instalați extensia PhpRedis pe serverul dvs. Oferă un API pentru ca PHP să comunice cu magazinul cheie-valoare Redis.
sudo apt-get install php-redis
Reporniți serverul PHP după instalarea extensiei PhpRedis. O poți face cu următoarea comandă:
sudo service php7.3-fpm restart
Serverul lor web rulează cu versiunea PHP 7.3. Trebuie să utilizați o comandă corespunzătoare versiunii PHP a serverului dvs. web.
3.Trebuie să vă asigurați că serverul Redis are suficientă memorie alocată pentru a stoca cache-urile paginilor. Redis Page Cache vă recomandă să alocați cel puțin 16 MB doar pentru stocarea în cache a paginii. Puteți face acest lucru adăugând următoarea linie în fișierul conf:
maxmemory 256mb
Au alocat 256 MB serverului Redis. Deoarece pluginul comprimă memoria cache folosind gzip pentru a reduce utilizarea memoriei, ar trebui să fie mai mult decât suficient pentru a stoca toate cache-urile paginilor.
Apoi, adăugați următoarea politică de memorie pentru a vă asigura că Redis evacuează memoria cache mai veche pentru a face loc celor noi.
maxmemory-policy allkeys-lru
Reporniți serverul Redis după salvarea modificărilor în fișierul de configurare. Iată comanda pentru a reporni Redis:
sudo systemctl restart redis.service
4.Acum trebuie să instalați și să activați pluginul Redis Page Cache. Puteți să-l instalați manual din depozitul său open source GitHub sau direct prin WordPress.org.
Dacă instalați pluginul direct prin WordPress.org, slug-ul pluginului (sau numele directorului său) este pj-page-cache-red. Dar dacă îl descărcați direct prin depozitul său GitHub, slug-ul este redis-page-cache. Amintiți-vă de unde ați instalat, deoarece trebuie să utilizați slug-ul corect în pasul următor.
5.În continuare, trebuie să creați un link simbolic (link simbolic sau scurtătură) în directorul wp-content care face legătura cu fișierul advanced-cache.php inclus în plugin.
Pentru a face asta, mai întâi trebuie să schimbați directorul terminalului în folderul wp-content folosind comanda cd.
cd /var/www/your-domain.com/wp-content
Acum puteți crea o legătură simbolică în directorul wp-content folosind comanda ln -s.
sudo ln -s plugins/pj-page-cache-red/advanced-cache.php advanced-cache.php
6.În cele din urmă, trebuie să activați memoria cache a paginii pe site-ul dvs. WordPress prin editarea fișierului său wp-config.php. Adăugați următorul fragment de cod deasupra liniei care spune /* Asta e tot, nu mai editați! Blogging fericit. */
define( 'WP_CACHE', true );
Locația în care adăugați fragmentul de cod de mai sus este foarte importantă.
Ați terminat de configurat Redis Page Cache pentru site-ul dvs. WordPress.
Înainte de a testa încărcarea site-ului web, să verificăm dacă memoria cache a paginii funcționează conform intenției. Puteți testa acest lucru vizitând site-ul în modul incognito sau utilizând comanda cURL:
curl -v https://exemplu.ro -o/dev/null
Înlocuiți https://exemplu.ro cu numele dvs. de domeniu.
Dacă memoria cache a paginii funcționează conform intenției, atunci ar trebui să vedeți un antet de răspuns X-Pj-Cache-Status cu valoarea hit.
< X-Pj-Cache-Status: hit
Dacă valoarea afișată este „miss – lipsă” prima dată, încercați să rulați din nou comanda sau să reîmprospătați pagina. Trebuie să faceți acest lucru deoarece memoria cache este salvată numai după ce pagina a fost încărcată cel puțin o dată.
Felicitări, ați verificat acum că Redis Page Cache funcționează pe site-ul dvs. web.
De asemenea, puteți configura pluginul Redis Page Cache pentru a defini cum ar trebui să funcționeze. Pentru acest exemplu, ei au rămas la setările implicite.
Test de Stres cu Redis Page Cache Activat
Au testat din nou site-ul inactiv pentru a vedea cum rezistă cu Redis Page Cache activat. Tot prin loader.io și au efectuat testul de încărcare cu numărul maxim de clienți concurenți setat la 100.
Au repetat testul de cinci ori pentru a se asigura că rezultatele sunt consistente. Cu un timp mediu de răspuns de 478 ms și fără erori, putem concluziona că site-ul funcționează splendid cu cache-ul paginii activat.
Pe măsură ce numărul de clienți concurenți crește (linia verde), timpul de răspuns rămâne relativ constant (linia albastră). Acesta este unul dintre cei mai buni indicatori că un server poate gestiona mulți utilizatori activi fără a afecta viteza de încărcare a paginii.
S-a executat din nou testul, dar de data aceasta cu maximum 200 de clienți concurenți.
Site-ul încă funcționează bine, fără erori și un timp mediu de răspuns de 757 ms.
În graficul de mai sus, veți observa o creștere a timpului de răspuns la marcajul de 22 de secunde. După acest punct, timpul de răspuns al serverului crește pe măsură ce numărul clienților activi crește. Potrivit unui studiu realizat de rackAID, trebuie să păstrați timpul de răspuns al serverului mai mic de 500 ms pentru a menține o experiență bună pentru utilizator.
La sfârșitul testului cu 200 de utilizatori activi, timpul de răspuns al serverului a urcat la peste 1200 ms. Este departe de a fi ideal.
Memorarea în cache este doar una dintre numeroasele modalități de a reduce timpul de răspuns al serverului. Pentru mai multe informații despre acest subiect, consultați articolul despre reducerea TTFB.
Servirea a 78 de clienți concurenți fără pierderi de performanță este excelentă. Presupunând că fiecare utilizator petrece în medie 2 minute pe orice pagină, aceasta se traduce prin deservirea a peste 1,5 milioane de solicitări de pagină în fiecare lună, fără probleme de server.
Să depășim mai mult limitele serverului. Îl vom testa din nou cu numărul maxim de clienți activi setat la 250.
Rezultatele par în concordanță cu testul anterior, dar de data aceasta 5,1% din răspunsurile serverului au fost erori HTTP 400/500. Privind fila Detalii, ne va oferi mai multe informații despre când au apărut pentru prima dată răspunsurile de eroare.
Erorile HTTP 500x au apărut pentru prima dată după 51 de secunde. Numărul total de clienți activi a fost de 218 în acest moment al testului.
Datele de mai sus vă vor oferi o idee corectă despre câți clienți activi poate gestiona site-ul fără erori.
Din testele de mai sus putem concluziona că Redis Page Cache îmbunătățește considerabil performanța site-ului. Acum să trecem la testarea site-ului cu NGINX FastCGI Cache activat.
Ce este NGINX FastCGI Cache?
NGINX este un server web popular, de înaltă performanță, care poate găzdui site-uri WordPress. Pe lângă faptul că este un server web, este folosit și ca proxy invers, proxy de e-mail, echilibrator de încărcare și cache HTTP.
Conform W3Techs, 32,1% dintre site-uri web sunt instalate pe un server web NGINX (25 mai 2020). Cele mai multe gazde WordPress axate pe performanță folosesc NGINX pentru a-și alimenta site-urile astăzi.
Memorarea în cache pe NGINX este alimentată în principal de modulul său FastCGI Cache. Conform unui test de benchmarking realizat de SpinupWP, NGINX FastCGI Cache a fost cea mai rapidă și cea mai eficientă soluție de stocare în cache a lotului.
Cum se Activează NGINX FastCGI Cache
Puteți activa NGINX FastCGI Cache numai pe un server web care are instalat NGINX. Deoarece s-a instalat deja NGINX ca server web, l-au resetat la configurația de bază pentru a elimina orice urmă de Redis.
Puteți afla cum să utilizați NGINX FastCGI Cache pe site-ul dvs. WordPress, vizitând articolul despre memorarea în cache NGINX. De asemenea, puteți consulta articolul nostru despre Conținut Dinamic în Cache pentru WordPress pentru un tutorial complet despre cum să activați NGINX FastCGI Cache.
Înainte de a testa site-ul, s-a verificat dacă FastCGI Cache funcționează pe site verificând anteturile de răspuns.
În continuare au trecut la testul de stres pe loader.io.
Test de Stres cu NGINX FastCGI Cache Activat
În primul rând, au testat site-ul setând numărul maxim de clienți activi la 100.
După cum era de așteptat, site-ul funcționează excepțional de bine după activarea memoriei cache a paginii. Timpul mediu de răspuns al serverului rămâne sub 400 ms chiar dacă numărul de clienți activi ajunge la 100 (numărul maxim stabilit de ei).
Acum s-a crescut numărul maxim de clienți activi la 200 și au repetat testul de stres.
Chiar și după creșterea numărului maxim de clienți activi, timpul mediu de răspuns al serverului rămâne sub 400 ms. Avem deja un câștigător clar.
Dar cât de departe putem împinge serverul? Loader.io vă permite să setați numărul maxim de clienți activi la 10.000. Deci, au testat cu această setare maximă pentru a vedea dacă serverul va ține pasul.
În mod surprinzător, serverul a ținut pasul. Cu toate acestea, rezultatele testului au arătat o rată de eroare de 19,7% (timeout-uri în acest caz) și un timp mediu de răspuns al serverului de 4464 ms.
Au continuat să reducă numărul maxim de clienți la jumătate pentru a afla limita de stres a site-ului cu NGINX FastCGI Cache activat. În cele din urmă, au ajuns la două numere.
Cu numărul maxim de clienți activi setat la 800, timpul mediu de răspuns al serverului este de 596 ms. Cu toate acestea, timeout-urile serverului încep spre sfârșitul testului după ce atinge 760 de clienți activi. Limita de stres pentru NGINX FastCGI Cache este de 3,5 ori mai mare decât cea observată cu Redis Page Cache.
Au efectuat un alt test de stres pentru a găsi numărul de clienți activi pe care serverul îi poate gestiona fără a compromite timpul mediu de răspuns (<500 ms). Pentru acest test, au stabilit numărul maxim de clienți concurenți la 500.
Timpul de răspuns al serverului ajunge la peste 500 ms la 44 de secunde și continuă să se miște în sus. Numărul de clienți activi în acest moment este de 375. Prin urmare, putem deduce că serverul poate gestiona 375 de clienți concurenți fără a afecta timpul de răspuns. Este de 4,8 ori mai mare decât numărul de clienți activi acceptați de Redis Page Cache.
Presupunând că fiecare utilizator petrece în medie 2 minute pe orice pagină, aceasta se traduce prin deservirea a 8,1 milioane de solicitări de pagini în fiecare lună, fără probleme de server. Nu e rău pentru un site găzduit pe un server de 10 USD/lună.
Rezumând Testele de Stres
Redis Page Cache este o implementare inteligentă a stocării în cache a paginii întregi pentru site-urile WordPress. În comparație cu faptul că nu este activată memorarea în cache a paginii, ajută la îmbunătățirea considerabilă a performanței site-ului.
Cu toate acestea, NGINX FastCGI Cache a depășit Redis Page Cache în toate testele de stres efectuate. Mai jos este o diagramă comparativă a ambelor teste de stres. Rezultatele sunt concludente și vorbesc de la sine.
Bonus – Server LiteSpeed Enterprise
Trebuie să afirm de la început că serverul LiteSpeed Web Server nu este gratuit ca cel mai folosit server web Apache. Unii preferă să încerce să configureze Apache cu Nginx și Varnish pentru a face memoria în cache și pentru a accelera conținutul static. Pentru a accelera PHP, ei configurează Opcache sau un alt mecanism php gratuit de memorie în cache.
Dar, cu toate configurațiile personalizate, este greu să te apropii de performanța și eficiența LiteSpeed. Mai mult, astfel de optimizări personalizate duc la probleme aleatorii și timp de dezactivare pentru site-urile web. Va trebui să reporniți Varnish/Nginx pentru a „rezolva” problemele ciudate. LiteSpeed este câștigătorul aici și singurul dezavantaj este că trebuie să plătiți pentru asta.
Test de Stres cu LiteSpeed Pentru Comunitatea WordPress
Am efectuat câteva teste de stres și anume:
- 100 de clienți pe minut
- 250 de clienți pe minut
- 500 de clienți pe minut
- 1000 de clienți pe minut
- 10.000 de clienți pe minut ( maxim admis pentru contul gratuit pe loader.io )
100 de clienți pe minut
250 de clienți pe minut
500 de clienți pe minut
1.000 de clienți pe minut
10.000 de clienți pe minut
În urma efectuării testelor de stres pentru site-ul Comunitatea WordPress care folosește server LiteSpeed, diferența este covârșitoare, comparativ cu testele efectuate în acest articol pe Redis și NGINX. După cum ați observat, cu cât numărul de clienți pe minut este mai mare, timpul de încărcare scade. Comunitatea WordPress nu folosește Digital Ocean, are un cont de găzduire personalizat la NameBox pe server LiteSpeed stocat în Germania.
Resurse pe Hosting-ul NameBox:
- Spațiu pe Disc – 120 GB SSD NVMe
- Ram – 4 GB
- Procesor – 200% Vcpu
- 100 de lei/lună
Concluzie
Nu aveți nevoie de găzduire costisitoare pentru a optimiza performanța site-ului dvs. dacă știți cum să activați stocarea în cache a paginii. Aproape toate gazdele WordPress gestionate fac exact acest lucru pentru a accelera site-urile WordPress.
Dacă doriți să vă aprofundați, puteți asocia NGINX FastCGI Cache cu memorarea în cache a obiectelor Redis pentru a optimiza și mai mult performanța site-ului. Există o configurație personalizată NGINX pentru WP Rocket numită Rocket-Nginx. Acesta permite NGINX și WP Rocket să servească fișiere stocate în cache direct, fără a apela WordPress sau a rula PHP.
Memorarea în cache a paginii este o alegere excelentă pentru a vă accelera site-ul. Alegerea soluției potrivite de stocare în cache a paginii pentru site-ul dvs. WordPress poate fi foarte confuză. Sper că acest articol a răspuns la unele dintre îndoielile tale și ați înțeles diferența între Redis Cache vs NGINX FastCGI Cache pentru WordPress.
