O privire asupra stivei moderne de servere WordPress

Îți amintești când ai putea rula un site WordPress „rapid” doar cu un server Apache și PHP? Da, acelea erau zilele! Lucrurile erau mult mai puțin complicate pe atunci.

Acum, totul trebuie să se încarce fulgerător! Vizitatorii nu au aceleași așteptări cu privire la timpii de încărcare ca înainte. Un site web lent poate avea implicații grave pentru dvs. sau clientul dvs.

Citiți suplimentare despre SmashingMag:

• Permisiuni și proprietăți adecvate ale sistemului de fișiere WordPress
• Mutarea unui site web WordPress fără bătăi de cap
• Cum să dezvoltați WordPress local cu MAMP
• Metode de stocare în cache pe cont propriu cu WordPress

În consecință, stiva de servere WordPress a trebuit să evolueze de-a lungul anilor pentru a ține pasul cu această nevoie de viteză. Ca parte a acestei evoluții, au trebuit adăugate câteva trepte de viteză la motorul său. Unele dintre treptele mai vechi au trebuit să se schimbe, de asemenea.

Rezultatul este că stiva de servere WordPress arată destul de diferit astăzi față de acum câțiva ani. Pentru a înțelege mai bine, vom explora această nouă stivă în detaliu. Veți vedea cum se potrivesc diferitele piese pentru a face un site web WordPress rapid.

Prezentare generală

Înainte de a ne scufunda, să micșorăm și să privim imaginea de ansamblu. Cum arată această nouă stivă de servere WordPress? Ei bine, iată răspunsul:

Diagrama de mai sus oferă o imagine de ansamblu bună despre cum arată stiva modernă de servere WordPress. La un nivel înalt, putem împărți ceea ce se întâmplă în trei domenii:

• ciclul cerere-răspuns între browser și WordPress;
• WordPress (care este un script pe care runtime-ul PHP îl execută);
• ciclul de interogare-rezultat între WordPress și baza de date MySQL.

Rolul stivei moderne de servere WordPress este de a optimiza aceste trei zone. Aceste optimizări fac totul să se încarce mai repede. Și cea mai bună parte este că există mai multe moduri de a face acest lucru. (Yay!)

În cele mai multe cazuri, aceste optimizări presupun instalarea de noi servicii pe serverul dumneavoastră. Uneori, aceste servicii vor avea nevoie de ajutorul unui plugin pentru a interacționa cu WordPress. Vor exista, de asemenea, momente în care puteți scăpa doar instalând un plugin. Veți vedea o mulțime de opțiuni diferite de-a lungul acestui articol.

Ciclul Cerere-Răspuns

Totul începe cu browserul. Să presupunem că doriți să vizualizați pagina de pornire a modern.wordpress-stack.org . Browserul dvs. va începe prin a trimite o solicitare HTTP către serverul web care îl găzduiește. La celălalt capăt, serverul web vă va prelua cererea și o va transforma într-un răspuns HTTP.

Acest prim răspuns ar trebui să fie întotdeauna conținutul HTML al paginii de start a modern.wordpress-stack.org (cu excepția cazului în care există o eroare). Cu toate acestea, treaba browserului dvs. nu este finalizată. Nu, pagina de pornire are nevoie de mai multe fișiere, cele mai comune fiind fișierele CSS, JavaScript și imagini.

Deci, browserul va trimite cereri pentru acele fișiere. Serverul web va răspunde cu fișierele solicitate (din nou, atâta timp cât nu există erori). Acest ciclu va continua până când browserul are suficiente informații pentru a reda pagina de pornire. Cu cât acest ciclu are loc mai repede, cu atât site-ul web va părea să se încarce mai repede.

Acum, aceasta este o simplificare evidentă, dar așa funcționează lucrurile pentru majoritatea site-urilor WordPress.

Optimizarea ciclului cerere-răspuns

În regulă, asta ne aduce la întrebarea evidentă, Cum facem ca un server web să efectueze acest ciclu mai rapid? Aceasta este o întrebare grozavă și face parte din motivul pentru care există stiva modernă de servere WordPress.

Stiva există pentru că nu poți să faci un server web mai rapid. Un server web este, de asemenea, un dispecer. Poate primi o solicitare și doar o redirecționează către alte servicii.

Aceste alte servicii sunt adesea blocajul acestui ciclu cerere-răspuns. Cu WordPress, acest blocaj este PHP, motiv pentru care optimizarea ciclului cerere-răspuns se reduce la două lucruri. Dorim ca serverul web să:

• primiți cât mai puține solicitări,
• transmite cât mai puține solicitări către PHP.

Stiva modernă de servere WordPress se concentrează pe aceasta din urmă. Vrea să trimită cât mai puține solicitări către PHP. Acesta va fi obiectivul principal pentru optimizarea stivei.

Ne concentrăm pe cel de-al doilea obiectiv pentru că stiva nu poate face mare lucru în privința primului; nu are impact direct asupra ei. Al doilea este adresat fie de configurarea serverului web, fie de tehnici moderne de dezvoltare.

Stack Elemente pentru ciclul cerere-răspuns

Deci, care sunt elementele stivei care ne vor ajuta să reducem solicitările transmise către PHP? Ei bine, două elemente de stivă în special ne vor ajuta să atingem acest obiectiv: serverul web și cache-ul HTTP.

Server Web

Am vorbit deja destul de mult despre serverele web. Există trei jucători mari în spațiul serverului web:

• Apache
• Internet Information Services (IIS)
• nginx

Împreună, acestea reprezintă mai mult de 90% din cota de piață a serverelor web de pe Internet. Ne vom concentra pe Apache și nginx. Deși IIS poate fi folosit pentru a rula WordPress, nu este obișnuit, deoarece este disponibil numai pentru Windows, iar majoritatea serverelor WordPress folosesc Linux.

Acest lucru ne lasă cu Apache și nginx. Pentru toată viața WordPress, Apache a fost serverul web recomandat. Aveam stiva LAMP (Linux, Apache, MySQL și PHP), care rula WordPress atât pe computer, cât și pe server.

Dar în culise, lucrurile se schimbau. Era un jucător nou în oraș și numele lui era nginx. Automattic și WordPress.com îl folosesc din 2008. Este serverul web care rulează cel mai mare procent de site-uri web cu trafic ridicat (dintre care multe rulează WordPress). De aceea, o mulțime de companii de găzduire de vârf și agenții de top WordPress îl folosesc ca server web.

Nu înseamnă că Apache este un server web prost. Există experți Apache care îl pot face să funcționeze grozav sub mult trafic. Pur și simplu nu se descurcă la fel de bine din cutie sau cu configurația standard WordPress.

Între timp, singurul scop al lui nginx este să gestioneze mult trafic. De aceea, Igor Sysoev a început proiectul când lucra la Rambler.

Unul dintre motivele pentru care nginx gestionează mai bine mai mult trafic este că folosește FastCGI pentru a comunica cu PHP. Ce este FastCGI? Este un protocol care permite PHP să ruleze ca un serviciu separat de serverul web.

Apache nu face acest lucru în mod implicit. De fiecare dată când serverul web primește o solicitare, trebuie să înceapă un proces de rulare PHP - chiar și pentru imagini, JavaScript și CSS. Acest lucru reduce numărul de solicitări pe care serverul le poate gestiona și cât de repede le poate gestiona.

Acest lucru contravine unuia dintre obiectivele stivei moderne de servere WordPress, pe care l-am văzut mai devreme. Stiva trebuie să mențină timpul ciclului cerere-răspuns cât mai scăzut posibil. Încărcarea PHP pentru fiecare solicitare, chiar și atunci când nu are nevoie de el, merge împotriva acestui obiectiv. Deci, dacă utilizați Apache, căutați în FastCGI.

HTTP/2 este o altă caracteristică importantă a serverului web despre care ar trebui să știți. Este următoarea versiune a HTTP, protocolul care alimentează întregul nostru ciclu cerere-răspuns.

Înainte de sosirea HTTP/2, un browser putea avea doar șase conexiuni la serverul web. Și fiecare conexiune ar putea gestiona o singură solicitare la un moment dat. Deci, în practică, un ciclu cerere-răspuns a fost limitat la șase solicitări pe ciclu.

Asta e o problemă reală. Majoritatea site-urilor web au zeci de solicitări în ciclul lor. Dezvoltatorii și administratorii de sistem au găsit modalități inteligente de a ocoli această limitare.

Una dintre cele mai cunoscute soluții este practica combinării fișierelor CSS și JavaScript. Într-un scenariu ideal, acest lucru ar reduce numărul total de solicitări pentru fișiere CSS și JavaScript la două: una pentru JavaScript și una pentru CSS.

Acest lucru nu este necesar cu HTTP/2. HTTP/2 permite un număr nelimitat de solicitări per conexiune. Acest lucru permite ca toate solicitările suplimentare după răspunsul HTML inițial să aibă loc în același timp.

Acest lucru are implicații uriașe de performanță. O mare parte din munca de optimizare a stivei de server se concentrează pe ciclul cerere-răspuns. Prin reducerea numărului de cicluri la doar câteva, HTTP/2 a lucrat enorm pentru noi.

Cache HTTP

Cea mai importantă parte a stivei moderne de servere WordPress este cache-ul HTTP. În lumea WordPress, numim și această pagină caching. Scopul cache-ului HTTP este de a stoca în cache răspunsurile la solicitări. Ce inseamna asta?

Ei bine, să revenim la exemplul nostru anterior. Browserul trimite o solicitare pentru pagina de pornire a modern.wordpress-stack.org , iar serverul web primește acea cerere și o trimite către PHP.

Problema cu acest scenariu este că serverul web este prost. Acesta va redirecționa întotdeauna toate solicitările pe care le primește către PHP - indiferent dacă majoritatea solicitărilor vor genera același răspuns.

Este exact ceea ce se întâmplă atunci când vizitatorii nu sunt autentificați. Pentru serverul web, toate sunt cereri diferite, dar nu-i pasă. Le va trimite pe toate către PHP, care va genera același răspuns pentru toate.

Asta e teribil! După cum am văzut mai devreme, PHP este adevăratul blocaj al ciclului nostru cerere-răspuns. Browserul dvs. nu poate trimite solicitările sale de urmărire până când nu primește răspunsul inițial pe pagina de pornire. Nu putem avea ca serverul web să trimită totul către PHP în mod implicit.

Aici intervine cache-ul HTTP. Se află între serverul web și PHP. Sarcina sa este să verifice fiecare solicitare pe care o primește serverul web și să caute un răspuns în cache. Dacă nu există, va trimite cererea către PHP și apoi va stoca în cache răspunsul pe care îl generează PHP.

Acest lucru reduce drastic timpul ciclului cerere-răspuns, făcând site-ul să se încarce mai rapid. De asemenea, permite serverului web să gestioneze mai multe solicitări simultane fără să explodeze.

Diferite arome ale HTTP Cache

În acest moment, ar trebui să vă întrebați: „Cum pot pune acest copil pe serverul meu cât de curând?!” Vestea bună este că instalarea unui cache HTTP pe un server WordPress este destul de ușoară. Este componenta cu cea mai largă gamă de opțiuni.

Instalați un plugin pentru caching de pagini

Cea mai ușoară modalitate este să instalați un plugin de stocare în cache a paginii. Aveți câteva opțiuni din care să alegeți:

• Batcache
• Hyper Cache
• Activator cache
• WP Rocket
• WP Super Cache
• Cache total W3

Toate, cu excepția WP Rocket, sunt disponibile ca pluginuri gratuite în directorul WordPress. Deci, puteți instala unul și îl puteți testa imediat. Acestea fiind spuse, dintre cele patru plugin-uri, cel mai bun este WP Rocket. Deși este un plugin plătit, face mult mai mult decât să creeze un cache HTTP. Aceste alte beneficii măresc munca pe care o face cache-ul HTTP.

Cum funcționează un plugin de cache a paginii?

Toate aceste plugin-uri folosesc un drop-in pe care WordPress l-a pus la dispoziție pentru stocare în cache. Acest drop-in de cache permite pluginurilor să creeze un sistem cache HTTP în interiorul WordPress. Cacheul drop-in are nevoie de două lucruri pentru a funcționa.

În primul rând, fișierul drop-in advanced-cache.php trebuie să fie în folderul wp-content . Acesta este fișierul real. Dar, spre deosebire de majoritatea drop-in-urilor WordPress, acesta nu intră în mod implicit. De asemenea, WordPress are nevoie ca constanta WP_CACHE să fie true pentru a încărca drop-in-ul. În cele mai multe cazuri, ați seta asta în wp-config.php .

Diagrama de mai sus arată ce se întâmplă când activați drop-in-ul cu un plugin de cache. WordPress încarcă drop-in-ul în wp-settings.php în timpul procesului de încărcare. Acest lucru este suficient de devreme în proces încât WordPress nu a făcut încă nimic consumator de timp.

Pluginul de stocare în cache va verifica apoi dacă a stocat deja în cache răspunsul la cerere. Dacă da, va returna acel răspuns din cache. Dacă nu a făcut-o, va activa tamponarea de ieșire PHP și WordPress va continua să se încarce.

Acum, tamponarea ieșirii este un sistem interesant. Ceea ce face este să captureze toată ieșirea dintr-un script PHP într-o variabilă șir până când se întâmplă unul dintre cele două lucruri:

• îi spuneți PHP să înceteze să-și pună în tampon ieșirea folosind una dintre funcțiile încorporate,
• scriptul PHP se termină și trebuie să returneze un răspuns browserului.

Pluginul de cache se bazează pe ultimul scenariu. Vrea ca WordPress să-și facă treaba și apoi să memoreze în cache întreaga ieșire înainte ca PHP să o trimită înapoi în browser. Puteți vedea procesul în diagrama de mai jos.

Solicitați serverului web să o facă

Următoarea opțiune este să adăugați un cache HTTP la nivel de server web. Modul în care funcționează este că serverul web va stoca în cache toate răspunsurile la solicitările care sunt transmise către PHP. Această soluție este mai bună decât un plugin de cache, deoarece nu trebuie să atingă PHP deloc.

Diagrama de mai sus oferă o imagine de ansamblu asupra a ceea ce se întâmplă în serverul web. Serverul web primește o solicitare și verifică cu cache-ul HTTP. Dacă un răspuns a fost deja stocat în cache, cache-ul HTTP îl va trimite înapoi.

În caz contrar, va trimite cererea către modulul PHP (de obicei FastCGI). Va transmite cererea către WordPress, astfel încât să poată genera un răspuns. Modulul cache HTTP va stoca apoi acel răspuns în cache la întoarcere.

Atât Apache, cât și nginx vin cu capacitatea de a adăuga un sistem cache HTTP. Cel nginx este încorporat. Cel Apache este un modul separat pe care trebuie să îl adăugați la instalarea Apache.

Nu există multe informații despre cum să utilizați modulul Apache cu PHP sau WordPress. Acest lucru s-ar putea datora faptului că nu este popular printre mulțimea Apache sau poate pentru că are unele probleme. Există cel puțin o problemă de lungă durată, care este încă deschisă.

Între timp, sistemul de cache HTTP nginx este robust și bine documentat. Îl puteți folosi ca cache HTTP normal sau ca micro-cache mai mic, dar eficient. Este doar un motiv în plus pentru care nginx este serverul web preferat în zilele noastre.

Adăugați lac la stivă

Ce este Varnish? Este un server cache HTTP dedicat (sau, așa cum le place dezvoltatorii săi să-l numească, accelerator HTTP). Cele mai multe site-uri web cu trafic ridicat și companii de găzduire premium îl folosesc ca soluție cache HTTP.

Îl folosesc pentru că este puternic și oferă cea mai mare flexibilitate. Varnish are propriul limbaj de configurare, numit VCL. Vă permite să controlați fiecare element al procesului de stocare în cache. Varnish vine, de asemenea, cu o mulțime de instrumente pentru analizarea a ceea ce face memoria cache și a modului în care funcționează.

Acestea sunt diferențele majore între utilizarea acestuia și doar utilizarea cache-ului HTTP încorporat pentru serverul web. Cache-ul HTTP al serverului web încorporat este super-performant, dar și destul de simplu. Nu aveți prea mult control dincolo de câteva opțiuni de configurare.

Cu toate acestea, această putere și flexibilitate au un preț. Varnish este, de asemenea, cea mai complicată opțiune de cache HTTP. Nu face altceva decât să memoreze în cache răspunsurile HTTP. Nu se ocupă de terminarea SSL, ceea ce doresc (sau ar trebui să-și dorească majoritatea dezvoltatorilor WordPress). Aceasta înseamnă că stiva noastră modernă de servere WordPress va fi mai complexă atunci când o vom folosi.

Diagrama de mai sus ilustrează această complexitate suplimentară. Mai avem acum două componente în stiva noastră de servere WordPress: Varnish și un proxy invers.

Proxy-ul invers este acolo pentru a depăși limitarea pe care o are Varnish cu SSL. Se așează în fața lui Varnish și decriptează cererile pe care le primește serverul nostru. De asemenea, puteți numi acest tip de proxy invers un proxy de terminare SSL. Proxy-ul trimite apoi aceste cereri decriptate către Varnish pentru a le procesa.

Odată ce o solicitare ajunge pe Varnish, se lansează fișierele de configurare VCL. Sunt creierul lui Varnish. De exemplu, ei îi spun cum să:

• analiza, curata si modifica cererile primite;
• căutați un răspuns în cache;
• analizați, curățați și modificați răspunsurile care revin de la WordPress;
• memorează în cache aceste răspunsuri returnate;
• gestionează o solicitare de a elimina unul sau mai multe răspunsuri din cache.

Acesta din urmă este deosebit de important. Lăsat singur, Varnish nu are de unde să știe când WordPress dorește să elimine o pagină din cache. Deci, în mod implicit, dacă modificați o postare și o actualizați, vizitatorii vor continua să vadă aceeași pagină stocată în cache. Spre norocul nostru, există un plugin care elimină paginile din memoria cache Varnish.

WordPress

În regulă, solicitarea noastră pentru pagina de pornire a modern.wordpress-stack.org a ajuns pe WordPress. A trecut prin ciclul cerere-răspuns pe care tocmai l-am acoperit. Cache-ul HTTP a făcut tot ce a putut pentru a găsi un răspuns HTTP pe care să îl trimită înapoi.

Dar nu a existat un răspuns HTTP memorat în cache de trimis înapoi către browser. În acel moment, cache-ul HTTP nu avea altă opțiune. A trebuit să trimită cererea HTTP către WordPress.

Totul este acum în mâinile WordPress. WordPress trebuie să transforme cererea noastră HTTP într-un răspuns HTTP și să o trimită înapoi în memoria cache HTTP. După cum am văzut mai devreme, acesta este principalul blocaj al întregii noastre stive moderne de servere WordPress.

Cauza acestui blocaj este dublă. WordPress are mult cod PHP de executat. Acest lucru necesită timp și cu cât PHP o face mai lent, cu atât este nevoie de mai mult timp.

Celălalt blocaj sunt interogările bazei de date pe care WordPress trebuie să le efectueze. Interogările de baze de date sunt operațiuni costisitoare. Cu cât sunt mai multe, cu atât WordPress devine mai lent. Acesta va fi punctul central al ultimei secțiuni privind ciclul interogare-rezultat.

Optimizarea Runtime PHP

Să revenim la PHP. În acest moment, WordPress are o cerință minimă de PHP 5.2. Această versiune de PHP are aproape 10 ani! (Echipa PHP a încetat să-l sprijine în 2011.)

Echipa PHP nu a stat inactiv în toți acești ani. Au fost aduse numeroase îmbunătățiri ale performanței, în special în ultimii ani. Să ne uităm la ce poți face pentru a-l optimiza în zilele noastre.

Utilizați cea mai recentă versiune de PHP

Cel mai simplu lucru pe care îl puteți face este să vă actualizați versiunea de PHP. Versiunile 5.4, 5.5 și 5.6 au înregistrat îmbunătățiri de performanță. Cea mai mare îmbunătățire a fost de la 5,3 la 5,4. Trecerea la acesta a crescut performanța WordPress cu o sumă decentă.

Instalați Opcode Caching

Opcode cache este o altă modalitate de a accelera PHP. Ca limbaj de scripting pe server, PHP are un mare defect: trebuie să compileze un script PHP de fiecare dată când îl execută.

Soluția la această problemă este să memorați în cache codul PHP compilat. În acest fel, PHP nu trebuie să îl compileze de fiecare dată când îl execută. Aceasta este treaba cache-ului opcode.

Înainte de PHP 5.5, PHP nu a venit la pachet cu un opcode cache. A trebuit să-l instalezi singur pe server. Acesta este un alt motiv pentru care utilizarea unei versiuni mai recente de PHP este mai bună.

Treceți la un compilator de generație următoare

Ultimul lucru pe care îl puteți face este să treceți la unul dintre cele două compilatoare de ultimă generație: fie HHVM de la Facebook, fie PHP 7, cea mai recentă versiune de PHP. (De ce PHP 7? Este o poveste lungă.)

Facebook și echipa PHP au construit aceste două compilatoare de la zero. Au vrut să folosească strategii de compilare mai moderne. HHVM utilizează compilarea just-in-time, în timp ce PHP 7 utilizează compilarea anticipată. Ambele oferă îmbunătățiri incredibile de performanță față de vechiul PHP 5.

HHVM a fost primul care a ajuns pe scena în urmă cu câțiva ani. O mulțime de gazde de top au avut mult succes cu acesta, oferindu-l ca compilator PHP principal.

Totuși, merită subliniat că HHVM nu este un compilator PHP oficial. Nu este 100% compatibil cu PHP. Motivul este că HHVM nu este conceput doar pentru a suporta PHP; este, de asemenea, un compilator pentru limbajul de programare Hack al Facebook.

PHP 7 este un compilator PHP oficial. Nu a mai existat de mult. Echipa PHP l-a lansat în decembrie 2015. Acest lucru nu a împiedicat unele companii de găzduire WordPress să îl susțină deja.

Vestea bună este că WordPress în sine este 100% compatibil cu ambele compilatoare! Vestea proastă este că nu toate pluginurile și temele sunt, deoarece versiunea PHP minimă pentru WordPress este încă 5.2.

Nimic nu îi obligă pe autori să își facă pluginurile sau temele să funcționeze cu aceste compilatoare. Deci, nu poți merge all-in cu unul dintre ei. Stiva dvs. ar trebui să revină întotdeauna la PHP 5.

Ciclul de interogare-rezultat

În acest moment, timpul de execuție PHP trece prin toate fișierele PHP WordPress și le execută. Cu toate acestea, aceste fișiere PHP WordPress nu conțin date. Acestea conțin doar codul WordPress.

Problema este că WordPress stochează toate datele sale într-o bază de date MySQL. Deci, pentru a ajunge la el, runtime PHP trebuie să interogheze baza de date. Serverul MySQL returnează rezultatul acelei interogări, iar runtime-ul PHP continuă apoi să execute fișierele WordPress PHP... ei bine, adică până când are nevoie din nou de date.

Acest dus și înapoi se poate întâmpla de la câteva zeci de ori la câteva sute de ori. (Ați putea dori să vorbiți cu dezvoltatorul dvs. dacă este cel din urmă!) De aceea este un blocaj major.

Optimizarea ciclului de interogare-rezultat

Scopul de optimizare aici este de a accelera timpul de execuție a fișierelor WordPress prin PHP. Aici interogările bazei de date sunt problematice. Tind să ia mai mult timp decât rularea unui cod PHP simplu (cu excepția cazului în care codul tău face ceva scandalos).

Modul evident de a remedia această problemă este reducerea numărului de interogări pe care WordPress trebuie să le efectueze. Și asta merită întotdeauna! Dar nu este ceva cu care stiva modernă de servere WordPress poate ajuta.

S-ar putea să nu putem reduce numărul de interogări pe care WordPress le face, dar nici nu avem opțiuni. Există încă două moduri prin care stiva ne poate ajuta să optimizăm ciclul interogare-rezultat. În primul rând, poate reduce numărul de interogări efectuate în baza de date. Și pentru acele interogări care ajung la baza de date, poate reduce timpul necesar pentru a le rula.

Aceste două opțiuni sunt ambele menite să facă același lucru: faceți PHP să aștepte cât mai puțin posibil pentru rezultatele din baza de date, ceea ce va face WordPress în sine mai rapid.

Stiva de elemente pentru ciclul interogare-rezultat

Să ne uităm la diferitele elemente ale stivei implicate în ciclul interogare-rezultat. Această parte a stivei este mai puțin complexă. Dar încă implică mai mult de o componentă - și anume, serverul de baze de date MySQL și cache-ul obiectelor.

Server de baze de date MySQL

Acum câțiva ani, un server de baze de date MySQL ar însemna același lucru pentru toată lumea. Era un server cu serverul MySQL instalat. Dar lucrurile s-au schimbat foarte mult în ultimii ani.

Diverse grupuri nu au fost mulțumite de modul în care Oracle gestiona proiectul MySQL. Așadar, fiecare grup l-a bifurcat și și-a creat propria versiune pe care o puteți „introduce” în schimb. Rezultatul este că acum există mai multe servere de baze de date MySQL.

Noul server MySQL „oficial” este serverul MariaDB. Este versiunea dezvoltată de comunitate a serverului MySQL. Comunitatea intenționează să mențină compatibilitatea deplină cu proiectul server MySQL.

O altă alternativă populară la MySQL este serverul Percona. Spre deosebire de MariaDB, Percona este mai degrabă o ramură a MySQL. Dezvoltatorii săi nu sunt împotriva proiectului MySQL în sine; vor doar să se concentreze pe îmbunătățirea performanței MySQL. Echipa MariaDB a fuzionat mai târziu unele dintre aceste îmbunătățiri de performanță în proiectul MariaDB.

La sfârșitul zilei, îl poți alege pe cel pe care îl preferi. Nu există nicio diferență de performanță între un server Percona și un server MariaDB (oricum pentru cei mai mulți dintre noi). Ambele au performanțe mai bune decât MySQL. Cu toate acestea, Percona menține o compatibilitate mai strânsă cu proiectul Oracle.

Ceea ce afectează performanța este motorul de stocare pe care îl folosește baza de date WordPress. Motorul de stocare controlează modul în care serverul de baze de date gestionează datele pe care le stochează. De asemenea, puteți seta un motor de stocare diferit pentru fiecare tabel de bază de date; nu trebuie să-l utilizați pe același pentru întreaga bază de date.

Un server de baze de date are mai multe motoare de stocare. Nu ne vom uita la toate. Doar două ne interesează: InnoDB și MyISAM.

În mod implicit, WordPress utilizează motorul de bază de date MySQL implicit. Înainte de MySQL 5.5, acel motor era MyISAM. Dacă rulați un site WordPress mic, atunci MyISAM este în regulă. MyISAM se confruntă cu probleme de performanță odată ce un site web crește în dimensiune. În acel moment, InnoDB este singura opțiune pentru un motor de bază de date.

Singura problemă cu InnoDB este că necesită anumite reglaje pentru a funcționa la cel mai bun nivel. Dacă rulați un server mare de baze de date, poate fi necesar să ajustați lucrurile. Din fericire pentru noi, există un instrument care să ne ajute în acest sens.

MySQLTuner este un mic script care analizează serverul dumneavoastră de baze de date. Acesta va genera un raport și vă va oferi recomandări de reglare.

Cache de obiecte

Greutatea muncii de optimizare a ciclului de interogare-rezultat constă în memoria cache a obiectelor. Sarcina memoriei cache a obiectelor este de a stoca date care necesită timp pentru a le obține sau a genera. După cum ați putea ghici, interogările de baze de date sunt candidatul perfect.

WordPress folosește foarte mult cache-ul obiectelor. Să presupunem că utilizați get_option pentru a obține o opțiune din baza de date. WordPress va interoga baza de date pentru acea opțiune o singură dată. Nu îl va mai interoga data viitoare când cineva are nevoie de el.

În schimb, WordPress va prelua rezultatul interogării din memoria cache a obiectelor. Acesta este un pas proactiv pe care WordPress îl face pentru a reduce numărul de interogări la baza de date pe care trebuie să le facă. Dar nu este o soluție sigură.

În timp ce WordPress va face tot posibilul pentru a valorifica memoria cache a obiectelor, un plugin sau o temă nu trebuie. Dacă un plugin sau o temă face multe interogări la baza de date și nu memorează în cache rezultatele, stiva nu poate face nimic în privința asta.

În astfel de cazuri, majoritatea interogărilor bazei de date vor veni de la WordPress însuși. Deci, veți obține un kilometraj grozav din utilizarea încorporată de către WordPress a memoriei cache a obiectelor. De aceea este un element important al stivei moderne de servere WordPress.

Acum, o problemă cu memoria cache a obiectelor este că nu persistă datele pe care le stochează în mod implicit. Stochează doar date în memorie în timp ce PHP execută toate fișierele WordPress. Dar odată ce procesul PHP se încheie, toate datele stocate în memorie sunt șterse.

Acest lucru nu este deloc ideal. O memorie cache a obiectelor poate rămâne valabilă mult timp, așa că nu doriți să-l limitați la o singură solicitare. Soluția este să folosiți un cache de obiecte persistent .

Un cache a obiectelor persistente vine adesea sub forma unui plugin. Acest plugin ar folosi drop-in-ul object-cache.php pentru a-și face treaba. Acest drop-in le permite autorilor de plugin-uri să modifice comportamentul implicit al cache-ului obiectelor.

Pluginurile conectează apoi memoria cache a obiectelor la un depozit de date persistent. Ei fac asta prin înlocuirea funcționalității de preluare și salvare a cache-ului implicit al obiectelor. În loc să salveze și să preia date în memorie, memoria cache a obiectelor o face din acel magazin.

Pluginuri persistente pentru cache de obiecte

În zilele noastre, există două opțiuni populare de stocare de date pentru stocarea în cache a obiectelor persistente:

• Memcached (plugin)
• Redis (plugin)

Ambele depozite de date folosesc RAM pentru stocare, ceea ce le face fulgerătoare. De fapt, performanța lor este comparabilă cu cea a cache-ului implicit al obiectelor.

Singura problemă este că nu vin preinstalate pe servere. Și nici extensia lor PHP (care este opțională cu Redis). Trebuie să instalați unul înainte de a putea utiliza pluginul WordPress corespunzător.

Pe care ar trebui să-l instalezi? În practică, nu există o mare diferență între cele două pentru stocarea în cache a obiectelor. În trecut, opțiunea populară era Memcached. Acest lucru s-a schimbat în ultimii ani. Redis a adăugat o mulțime de caracteristici care l-au făcut opțiunea de bază pentru stocarea în cache a obiectelor.

Obțineți propriul dvs. server WordPress modern

Deci, cum vă obțineți propriul server? Modul evident este să obțineți unul de la o companie de găzduire WordPress de top. Aceste companii doresc să rămână în fruntea afacerii de găzduire WordPress, ceea ce le motivează să adopte cele mai recente descoperiri și tehnologii.

Dar dacă vrei unul fără să spargi banca? Câteva instrumente sunt disponibile pentru oricine ar prefera să o facă singur și să plătească mai puțin pentru găzduire. Să ne uităm la ele.

DebOps pentru WordPress

DebOps pentru WordPress este un instrument pe care l-am creat pentru a ajuta pe oricine să construiască un server WordPress modern. Misiunea sa este de a face stack-ul modern de server WordPress disponibil pentru oricine din comunitate. De aceea, încerc să-l fac cât mai ușor de utilizat. Nu aveți nevoie de cunoștințe de administrare a sistemului pentru a-l folosi.

DebOps pentru WordPress configurează un server cu următoarele:

• HHVM (până când PHP 7 îl transformă într-un depozit oficial Linux)
• MariaDB
• nginx
• Redis
• Lac

Instrumentul face mai mult decât configurarea unui server cu cele mai noi tehnologii. De asemenea, are grijă să vă securizeze serverul. Acesta este un lucru pe care oamenii îl ignoră adesea atunci când își gestionează propriul server.

EasyEngine

EasyEngine este un instrument de linie de comandă conceput pentru a vă ajuta să configurați un site web WordPress pe un server. Lucrul minunat despre EasyEngine este flexibilitatea sa: îl puteți utiliza pentru a configura aproape orice combinație de tehnologii de server pe care le-am analizat până acum.

De exemplu, vă permite să configurați un server fie cu HHVM, fie cu PHP 7. Vă permite să alegeți între Memcached și Redis pentru depozitul de date persistente. Și vă permite să instalați instrumente de administrator, cum ar fi phpMyAdmin.

De asemenea, oferă un număr mare de opțiuni atunci când creează un site web WordPress. Îi puteți spune să configureze un site web cu un cache HTTP folosind un plugin sau nginx. Toată această flexibilitate este motivul pentru care EasyEngine este un instrument atât de popular.

Spalier

Trellis este un instrument dezvoltat de Roots. La fel ca DebOps, configurează serverul cu un set specific de tehnologii de server:

• MariaDB
• Memcached
• nginx
• Cache HTTP nginx (opțional)
• PHP 7

Un lucru de știut despre Trellis este relația sa cu Bedrock, un alt instrument construit de Roots. Bedrock este un standard pentru structurarea unui site web WordPress în jurul principiilor „Twelve-Factor App”.

Echipa Roots a creat Trellis pentru a le permite oamenilor să configureze un server care utilizează site-uri web WordPress structurate în Bedrock. Nu îl puteți folosi cu o instalare WordPress normală, așa că rețineți asta.

Vremurile s-au schimbat

După cum puteți vedea, un server WordPress are astăzi mult mai multe părți mobile! Dar acest lucru nu trebuie să fie un motiv de disperare. Nu este atât de rău pe cât pare, deoarece nu trebuie să folosiți întotdeauna toate piesele.

De aceea, atât de mult din acest articol discută despre modul în care aceste părți funcționează împreună. Ideea este să vă împuterniciți să luați propriile decizii. Folosiți aceste cunoștințe pentru a decide ce părți trebuie să utilizați și când. În acest fel, vei avea și tu un site web WordPress rapid.