Kodulehe kiirus ja allkriips, mis oleks võinud nurjata esmaspäeva

“Mu veeb / veebipood käib aeglaselt, kas teie juurde kolides / suurema paketiga / pilveserveriga läheks kiiremaks?” on üsna sage küsimus ja küll oleks tore “Jah!” vastata.

Reaalsus on paraku natuke keerulisem ning päädib sageli sellega, et me aitame üles leida veebi aegluse põhjuse. Mõni nädal tagasi toimus Eesti E-kaubanduse Liidu kampaania e-smaspäev ning pärast osalevate e-poodide lisamist – “reedel enne e-smaspäeva” muutus veeb aeglaseks.

Kohe nii aeglaseks, et mõnikord võttis lehe kuvamine 20 sekundit. “Meie juurde kolimine” vähendas selle küll 16,4 sekundi peale, aga kasutaja jaoks tähendab see endiselt, et “veeb on maas”. Privaatserver mille peale me oleme ürituse ajaks näiteks Simple Sessioni tõstnud oleks ühe lehe jaoks overkill, lisaks jääks aegluse põhjust teadmata risk alles.

Mis siis teha?

Pildirohke lehe puhul on sageli probleemiks nende suurus või kogus – ja kuigi Kuidas ma näen, et see HTTP/2 ikka töötab? eksperiment kasutab samu logosid, polnud see sedapuhku probleemiks. Kampaanialeht kasutas juba “laiska laadimist” ehk tõmbas alla ainult need pildid, mida parasjagu kuvada vaja oli.

Keerulise ent mitte muutuva sisu puhul saaks abi WP Super Cache pluginast, mis talletab kokkupandud lehed järgmiste kasutajate jaoks ning vähendab andmebaasi-päringute koormust, aga see on paraku vaid probleemi peitmine: kui puhver uuendamist vajab, saab keegi ikkagi viivituse osaliseks. Leht võiks käia tavaolukorras kiiresti ja cache aitaks toime tulla suurte koormustega. Ilmselt on sedapuhku teema või mõne plugina koodis midagi, mis piltide lisandumisel hakkab aina aeglasemalt toimima.

Arendajal on veebilehe koodi optimeerimiseks mitmeid võimalusi – meil oli aga leht juba avalikus serveris väljas, kasutusel ostetud kujundusteema, aega vähe ning ka probleem ilmnes alles koostöös serveri koormusega. Selles olukorras on vaid üks lihtne lahendus:

New Relic

Jah. Zone Virtuaalserveris on (hetkel käsitööna ning eriliste teenete eest) võimalik lisada kasutaja-kohane New Relic‘u litsents, monitoorida selle abil veebirakenduste jõudlust nii serveris jooksva koodi kui kasutajate brauserite poolelt, tellida teavitused kiiruse kukkumise puhuks jne jne. New Relic on selle juhtumi kontekstis totaalne overkill, aga kui kampaania on ukse ees võib 9.70€ kuumaksuga serverile $75 kuumaksuga monitooringu lisamine väga ahvatlev tunduda.

Esimene pilt mida õhtul nägime oli selline, pärit enam-vähem normaalse kiirusega lehekuvamisest:

Mis see kole pruun om_sc_speaker on? Mõistagi see koodijupp, mis kuvab lehel 120+logo. Ja miks ta aeglane on?

 if($photo) {
   $photo_=om_http2local($photo);
   if(stripos($photo_, 'http') !== 0)
     $im_size=@getimagesize($photo);
   else
     $im_size[3]='';
 }

WordPress teab kõigi piltide suurusi peast, aga keegi kavalpea Expo18 teema loonud kollektiivist on otsustanud viimasel hetkel – täpsemalt igal viimasel hetkel ehk lehekuvamisel – suurused üle kontrollida.

Eemaldades katseks koodijupi käib veeb nagu “lepase reega”, 75$ tagasiteenimiseks (kampaania võib julgelt alata!) kulus chati-logide järgi alla poole tunni.

E-smaspäeva käigus jäi lehe laadimiseks kuluv aega alla 1 sekundi, kampaania-surve lõppedes paranes veel veidi:

Aga siin on peidus veel üks õppetund – mis siis koodis valesti oli? Programmi loogikat jälitades saab selgeks, et om_http2local teisendab pildi avaliku URLi selle ketta-asukohaks ning sadakond kettapäringut ja pildifailide meta-infost suuruse lugemine ei tohiks kuidagi probleemiks olla.

Ainult et…

[...]
   $photo_=om_http2local($photo);
[...]
     $im_size=@getimagesize($photo);
[...]

Allkriipsu muutuja nime lõpus märkad? Kord on, kord mitte. Mina ei märganud umbes 2 tundi. Põrgus on olemas eraldi katel nende progejate jaoks, kes selliseid muutujanimesid kasutavad – ja ma luban, et käin seal perioodiliselt hagu alla viskamas (skeptikuna ma mõistagi ei usu paradiisi olemasolu, seega põrgus kohtume :).

Ehk siis tänu kehvalt nimetatud muutujale ei märganud ei teema autor ega mina, et lehe kuvamisel tehti 120+ HTTP-päringut sellesama veebiserveri vastu. Igaüks neist eraldi TCP-ühendusena ehk tekitades iseenda pihta suunatud “juhmi teenustõkestusründe” (ingl.k dumb denial of service).

Tulles tehniliselt lainelt tagasi loo alguse juurde:

“Mu veeb / veebipood käib aeglaselt, kas teie juurde kolides / suurema paketiga / pilveserveriga läheks kiiremaks?”

Jah. Natuke. Võibolla. Selle lehe laadimise aeg vähenes antud juhul 20 sekundi pealt 16,4 sekundi peale – veebikülastaja seisukohalt on see aga endiselt “leht on maas”.

Aitas veebirakenduse jõudluse analüüs ja selle alusel tehtud üsna triviaalne koodimuutatus. Kas see sisaldub Virtuaalserveri hinnas? Kindlasti mitte, ajakulu jms ületab aastamaksu kohe, kui me hakkame ühte veebi remontima.

Aga kui sul on mure – näiteks veeb käib aeglaselt ja kampaania tulekul – siis tasub Zonega rääkida, vahest saame vastastikku kasulikult kaubale. Veidi tuge ja soovitusi veebi-arendajale, ajutine kolimine Nutikasse Privaatserverisse … küsida võib ikka 🙂