Pogosto opažam, da so Wordpress blogi počasni kot hudič… Ne vem zakaj, a večina ljudi še vedno ignorira Wp-Cache, ki je nepogrešljiv Wordpress-ov vtičnik. Še tako močan server bo brez konkretne optimizacije strani prikazoval počasi, preprosto zato, ker je čas prikazovanja strani v veliki meri neodvisen od procesorske moči. Wordpress je stabilna platforma in velika večina poizvedb na podatkovni bazi (query-ev) je optimizirana oz. vsaj solidno indeksirana. Tu gre za milisekunde, kar se tiče procesorja… Problem je drugje. Spodobno napimpan Wordpress, med katerega štejem tudi p4b.nu, se ob vsakem prikazu strani poveže z zunanjimi storitvami in s tem obogati vsebino. Naš blog se tako vsakič poveže na Flickr, del.icio.us, Google Calendar in Google Analytics. Od teh storitev dobi odgovor in nato vse skupaj spremeni v obliko, ki jo razume vaš brskalnik (HTML). Vse skupaj je, seveda, precej počasno in odvisno od trenutne odzivnosti omenjenih storitev.

Del pohitritev se nanaša na t.i. frontend optimizacijo ^(*1), o kateri sem že pisal. Bistvo pa je v cache-ingu in točno to vam Wp-Cache omogoča. Surovi (raw) HTML se vedno naloži neprimerno hitreje kot (PHP) skripta. S tem izgubite del odzivnosti (npr. naš #SURFER se zato posodobi vsake 2 uri), a prednosti so velikanske. Določenim skriptam (npr. #CACTUS) se mora Wp-Cache izogniti, saj bi bilo drugače glasovanje v veliki meri onemogočeno. Če za serviranje PHP-ja in MySQL-a še vedno uporabljate Windows-e, resno premislite o smiselnosti svojega početja. Ko sem izvajal meritve na svojem računalniku, je bila obremenjenost procesorja pri vsakem zahtevku v povprečju višja za okoli 40% v primerjavi z Linuxom. Enak hardware-a, enaka Apache konfiguracija, ekvivalenten php.ini. Za dodatno optimizacijo (na Linux-u z inštaliranim Wp-Cache) pa lahko uporabite še tale ukaz:

(predpostavimo, da je /var/www/blog/wp-content/cache) vaš cache direktorij:

#> mount -osize=50m -t tmpfs tmpfs /var/www/blog/wp-content/cache

Tako Linux “prepričate”, da ima vsebino vašo bloga (HTML) v RAMu, če je to le mogoče. Hitrost tega je neprimerno večja, kot povprečno branje trdega diska. Velikost pomnilnika je z zgornjim ukazom nastavljena na 50MB in jo lahko po želji spremenite. Seveda ga lahko malo “prešejkate” in premaknete v /etc/fstab in /etc/rc.local ter s tem zagotovite, da se bo izvedel ob vsakem ponovnem zagonu strežnika. Lahko pa uporabite tudi memcached.

Koliko pa s takimi triki dejansko pridobite? Ogromno. Naš website teče na več kot 6 let starem AMD Athlonu (ostalih specifikacij raje ne bom razkril, ker bi se smejali) in povprečni VDSL povezavi. Ista kišta gosti hkrati še 10 drugih spletnih strani, FTP strežnik, mail strežnik, DNS strežnik in monitoring orodja, služi mojim dnevnim torrent potrebam in vsako soboto avtomatično stream-a najnovejši Solid Steel, ki ga pretvori v iPod-u domač mp3 format. Brez slednjega pač ne gre… ker se cenim. :)

^(*1)
Leta nazaj sem naletel na spletno stran, kjer so naredil kapitalno napako in Javascript kodo za povezavo z Google Analytics vpisali v glavo strani, med ostale skripte. V najbolj nepravem trenutku je Google Analytics dobesedno “crknil” in stran se preprosto ni prikazala. Nauk zgodbe je, da Google Analytics premaknete tik pred zaključni </body> tag in s tem zagotovite pravilno nalaganje ostalega dela strani.