Dali je zbilja potreban WordPress managed hosting za jako posječene sajtove? Možda to može i jeftinije :)

Svi znamo da je WordPress dosta “teška” platforma, no to nije zato što je WordPress loš nego arhitektura WordPress CMS-a i baza podataka je koncipirana tako da se WordPress umjesto prvenstveno blog platforme može koristiti i u druge svrhe – webshop sustavi, oglasnici, e-learning platforme, itd. Zbog toga i baza podataka nije specijalizirana samo za objavu običnih blog postova nego i malo više od toga. Naravno čim je sustav programiran za širu namjenu onda nije najbolje moguće optimiziran za svoju primarnu namjenu.

Zbog toga zbog pojačane posječenosti na stranici dolazi i do potencijalnih problema ako je tema loše programirana ili ako se ne koristi neka vrsta cachinga (object, static…)

Zbog svega toga postoje tzv. “Managed WordPress hosting”.

Na takvim hostinzima na serveru su instalirani mehanizmi uglavnom za caching stranice i opće postavke servera su definirane na način da radi najbolje za WordPress CMS sustave.

Prema našem iskustvu to sve skupa funkcionira odlično i podrška je stvarno dobra (odgovori na poruke i rješavanje problema u roku od 30 minuta). No glavno pitanje je dali to u nekim slučajevima (visoko posječeni portal) vrijedi čak i 1500$ mjesečno???

Prije nastavka ove naše male radionice objasniti ću što je zapravo caching web stranica:

Kod svakog učitavanja stranice ili neke podstranice odvijaju se upiti na bazu podataka kao i generiranje HTMLa preko nekih od serverskih programskih jezika: PHP, .net, …
Međutim problemi obično ne nastaju ako je RPMova malo nego ako ih je recimo 400RPM/sek kao na portalu koji smo optimizirali. U takvom slučaju nastaje jedan veliki server response time ako ne i pad servera.

Tu preuzimaju kontrolu caching mehanizmi, dobro, i naravno način na koji je programirana glavna tema koja se koristi na portalu kao i odabir pluginova.

Što je caching?

  1. Možemo jedan rezultat SQL upita (recimo najkorištenije ključne riječi – “tags”) spremiti u nekakav objekt ajmo reči varijablu, koja će se ažurirati recimo jedanput u 60 minuta, time smo sveli jedan složeni upit koji se izvršava kod svakog učitavanja stranice na vrlo jednostavan upit na bazu koji će dohvatiti sadržaj tog složenog upita. Složeni upit će se izvršavati samo jedanput u 60 minuta ili u nekom drugom periodu koji smo definirali.
    U ovom slučaju tu odličan posao radi tzv. WordPress transient API.
  2. Rezultat svih upita na bazu i PHP procesiranja u obliku HTML-a koji posjetitelj vidi (učitavanje jedne podstranice portala) pospremiti ćemo na hard disk ili memoriju servera i servirati posjetitelju direktno sa hard diska ili memorije tako da preskačemo sve prethodno navedene operacije koje opterečuju server. Sadržaj generiranih html dadoteka ažurirati će se kod prve sljedeće promjene u sadržaju portala.
    Npr. Varnish, Litespeed caching..
  3. Korištenje CDN servisa: Cloudflare, MaxCDN prednost takvih servisa je što skrivaju pravi IP servera što drastično smanjuje mogućnost i uspjeh hakerskih napada na server.

 

NAŠ EKSPERIMENT: Unajmi dedicated server i konfiguriraj server sam

Za potrebe eksperimentiranja unajmili smo “čisti” dedicated server i našli najbolji način za konfiguriranje istog da radi što bolje sa našim jako posječenim WordPress portalom.

Prvo smo na server instalirali sve osnovno: PHP, MySQL, Apache (LAMP), prekopirali bazu podataka od 2GB!!! i 200GB ostalog contenta.

Prvi rezultati učitavanja stranice su bili poražavajući. Jedan posjetitelj (ja)- 3 sekunde za sve SQL upite i izvršavanje PHP skripti. Ne želim niti pomisliti kako bi to izgledalo sa 1500 posjetitelja online.

Nakon toga instalirali smo Varnish za caching HTML podstranica i rezultati su bili puno bolji – prvo učitavanje 3.2 sekunde, sljedeće učitavanje iste podstranice 0.22 sekunde 🙂 – e to je napredak.
No postoji jedan problem – nakon izmjene sadržaja portala promjene se ne vide momentalno nego tek nakon 10 minuta (tako je podešen Varnish). Naravno i za to postoji rješenje – između portala i Varnish servera može se uspostaviti komunikacija koja daje serveru do znanja da je sadržaj promijenjen i da se na toj podstranici napravi brisanje cachea. Uz višesatno pokušavanje postizanja istog nismo uspjeli ništa napraviti i prešli smo na drugi način – instaliranje LiteSpeed enterprise web servera umjesto trenutnog Apachea.

LiteSpeed enterprise web server

-Puna podrška za .htaccess
-Kompatibilnost sa PHP, Perl, Ruby, Python, Java programskim jezicima
-Server API: LiteSpeed SAPI (LSAPI), CGI, FCGI, AJPv13, Proxy
-Odličan dashboard za postavljanje servera i kreiranje virtualnih hostova kao i dodavanje novih ekstenzija, grafički prikaz posječenosti hostova i opterečenja servera
-Ono najbitnije – integriran caching sustav – generiranje statičnih HTML stranica i WordPress LiteSpeed plugin za purge cachea kada se mijenja sadržaj portala

Više detalja na: https://www.litespeedtech.com/products/litespeed-web-server/features

Nakon instalacije LiteSpeed Enterprise web servera – 4 CPU licenca, 65$ mjesečno postigli smo sljedeće:

  1. 1200 ms (New relic) prvo učitavanje početne stranice i nakon cachinga iste 124ms !!!
  2. Momentalno ažuriranje putem LiteSpeed cache WordPress plugina nakon promjena na stranici – u vlastite pluginove i temu moguće je dodati trigere na purge cachea željene stranice
  3. Nakon prebacivanja cijele konfiguracije na produkcijski server sa prosječno 1500 posjetitelja online i 400 requesta po minuti prosječni “server response time” u 24 sata: 310 ms prema New Relic monitoringu, uz dodatnu optimizaciju custom wordpress teme: 220ms

ZAKLJUČAK: Zadovoljni! :=)

 

SUMARIZACIJA SVEGA

Postavljanje dedicated servera

  1. Instalacija CentOS 7 operativnog sustava
  2. Postavljanje MariaDB baze podataka
  3. Instalacija i podešavanje LiteSpeed enterprise 4CPU web servera

Migracija i optimizacija portala

  1. Kopiranje svih datoteka preko montiranog mrežnog diska
  2. Dump i import MySQL baze od 2gb na novi server
  3. Optimizacija MySQL upita na WordPress temi i objektni caching putem WordPress Transient API-a

REZULTAT

Kinsta server – prema New Relic monitoringu prosječni server response u 24 sata: 1200 ms

Dedicated server koji smo sami konfigurirali – 220ms i 3 PUTA MANJI MJESEČNI TROŠAK ISTOG

Što je bolje?    …prosudite sami 🙂

 

P.S

Uskoro slijedi novi članak o WordPress transient API-u i opčenitoj optimizaciji WordPressa za što manje opterečenje na server