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.

esmaspaev

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:

esmaspaev-om_sc_speaker

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:

esmaspaev-pingdom
Kiirust oleks võinud monitoorida ka New Relicuga, aga see graafik on tehtud pingdom.com abil.

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 🙂

Kuidas ma näen, et see HTTP/2 ikka töötab?

HTTP/2 peaks muutma brauseri ja serveri suhtluse kiiremaks ning netist leiab nii kenasid demosid selle tõestuseks (nt Akamai, Gophertiles) kui võimalusi kontrollida HTTP/2 toe olemasolu oma veebil (nt keycdn).

Kuna kõigil Zone HTTPS-iga Virtuaalserveritel on nüüd HTTP/2 vaikimisi lubatud (vt: Järgmine veebilehtede turbonupp sisse lülitatud: HTTP/2) siis … kuidas näha, et see ka tegelikult toimib ja midagi kiiremaks teeb? Ja kust ma üldse näen, et brauser HTTP/2 ühendust kasutab?

Võttes nt zone.ee esilehel lahti brauseri inspektori (paremklõps > Inspector > Network), lisades kuvatavate veergude hulka Protocol’i ja laadides lehe uuesti peaks avanema selline pilt:

inspector-protocols-h2-spdy-1.1Nagu näha on enamus ühendusi h2 ehk HTTP/2, aga näha on ka mõned välised vanemaid protokolle kasutavad CDNid (millest ilmselt võiks nüüd loobuda, vähendamaks tehtavate ühenduste arvu).

HTTP/2 nähtav ja demotav kiiruse-võit tuleb sellest, et brauser saab küsida kõik lehe kuvamiseks vajalikud pildi/stiili/skripti-failid serverilt ühe TCP-ühendusega, määrates ühtlasi ära nende olulisuse. Server saab saata vastused parimas võimalikus järjekorras ning eriti nutikas server võib juba algsele päringule vastates anda kaasa nimekirja vajalikest lisafailidest ja need ühe hooga ka teele panna.

Kui viimane variant ehk server push välja arvata, ei vaja efektiivsem ühendus täiendavat seadistamist ehk HTTP/2 sisselülitamisega hakkasid kõik senised Zone Virtuaalserverite turvalised HTTPS-ühendused kasutama uut protokolli (kuigi teoreetiliselt toetab HTTP/2 ka mitte-turvalist ühendust on brauserivalmistajad öelnud, et nemad seda toetama ei hakka).

Lihtsaks testiks sattus näppu Eesti E-kaubanduse Liidu e-poodide sooduskampaania E-smaspäev, mille lehelt leiab 128 ühesuurust logo.

Välistamaks kõiki muid mõjusid genereerib lihtne skript (vt repo GIThubis) neist igal lehe-laadimisel unikaalsete nimedega pildipilve, täpselt sama skript on nähtav kolmelt URLilt:

Erinevuse nägemiseks tasuks seda teha mõne mobiilse või muul põhjusel mitte-kõige-kiirema ühenduse abil, sest kiire fiiberoptika otsas on päringu ja vastuse vahele jääv viivitus pea olematu.

Testides 10Mbps koduse ADSLi ja WiFi abil näeb erinevus välja selline (sedapuhku laetakse 2 komplekti logosid):

See katse pole mõistagi eriti teaduslik (kes teab mis mu koduvõrgus veel toimus, kogutud pole piisavalt andmeid ja arvutatud standardhälbeid) – aga video on lõikamata ja 5+5 järjestikust laadimist annavad empiirilise eelise HTTP/2 versioonile. Nagu laadimise mustrist näha tulevad HTTP 1.1 puhul pildid vastavalt brauseri poolt paralleelselt saadetud päringutele trobikondade kaupa, HTTP/2 puhul aga korrapäraselt järjekorras.

Millega veel testida? www.webpagetest.org Lubab katsetada erinevatest asukohtadest, Ardil on tavaks proovida Prahas oleva serveriga, tulemused sellised:

HTTP 1.1:

http1-ardi

HTTP/2:http2-ardi

Selle testi järgi annab HTTP/2 ca 26% võitu lehe laadimise kiiruses. Aga paraku on numbrid võrdlemisi ebastabiilsed, miska … olgu, lisame testlehele ka kiiruse mõõtmise performance.timing abil… Ja kordame vidos näha olevat eksperimenti ehk laeme üle 4G telefoni jagatud WiFi vaheldumisi kahte lehte, tehtud sai 39 laadimist ning tulemused on sellised:

HTTP 1.1  – keskmine 2281ms, mediaan 1815ms
HTTP/2 – keskmine 1682ms, mediaan 1315ms

Ehk siis HTTP/2 oli ka selles testis 26-28% kiirem kui HTTP 1.1, lisaks stabiilsem – kui välja arvata need kaks katse pikimat laadimisaega:

http1-http2-graph

(kellel huvi testi korrata, siis kood on GIThubis ja soovi korral võin reeta ka logide asukoha)

Testi kokkuvõtteks: kui su veebis on hulk pilte, skripte ja stiilifaile – näiteks on tegu optimeerimata Magentoga ehk valdava enamusega Magentodest – annab HTTP/2 kõvasti võitu ning tagab lehe kiirema ja sujuvama laadimise ka nõrgema ühenduse otsas. Kui lehel on aga vaid kaks pilti ning vajalik JS ja CSS on hoole ja armastusega paari faili kokku kogutud, pole effekt ilmselt eriti märgatav.

Aga server push, see peaks ju andma mega-edu?

Server push’i näide vajaks keerulisemat testi – ilmselt peaks tekitama olukorra, kus brauseril kulub aega tuvastamaks mida on vaja alla laadida ning siis üllatada teda faktiga, et kõik on juba saadetud. Ja mõistagi eeldaks push päris-saitides kasutuselevõtuks serveripoolset tuge, näiteks võiks sisuhaldustarkvara või selle cache-moodul panna kokku nimekirja kõigest vajalikust. WordPress jaoks on olemas HTTP/2 Server Push plugin ja meie arendajatel kirjutatud ka lisa-plugin WP Super Cache jaoks, aga …

… on mõned agad. Ja mitte ainult meil – väidetavalt 70% maailma HTTP/2 liiklusest käib läbi CloudFlare ja nad teatasid 28. aprillil, et toetavad nüüd ka server push’i: Announcing Support for HTTP/2 Server Push. Paraku ei suuda mina seal viidatud demolehelt mingit pushi toimimist tuvastada ning kui vaadata kommentaariumit on näha, et kõik justnagu katsetavad midagi, ent tulemust ei ole. Toimub intensiivne musta kassi otsimine pimedas toas.

Kes tahab proovida, siis vajaliku päise saadavad ka e-smaspäeva testid kui lisada päringule argument push – https://http2.miljonivaade.eu/?push. Paraku näib olevat mingi probleem Chrome’l, sest push’i puhul tehakse iga pildi kohta täiendav päring veendumaks, et see viimase sekundi jooksul muutunud pole (ja cache keelamise või Chrome Canary puhul tõmmatakse pilt ka 2x alla, torpedeerides edukalt kogu ürituse) – abi selle müstika lahendamisel on teretulnud. Jah, sama jama on läbi CloudFlare testides.

Firefox toimib muideks korrektselt, sellel pildil viitavad hallid mummud piltidele mis saadi (ilmselt) tänu server push’ile ja näha on ka jupike Link-headerist:

firefox-with-push

Kes tahab oma Zone Virtuaalserveris katsetada, siis võib teha nagu mina – lisasin kaks alamdomeeni mis viitavad samale kataloogile, tellisin mõlemale tasuta Let’s Encrypt serdi ja siis lülitasin ühel HTTP/2 toe välja, alamdomeeni puhul saab seda teha kui minna serverihalduses Veebiserver > Alamdomeenid > [vastav alamdomeen] > Muuda SSL tuge:

alamdomeen-http2

Ladusat lisalugemist (ja veidi vaidlust teemal kui palju ikka HTTP/2 eelist annab) leiab siit:

PHP 7 Apache moodulis ja /usr/bin/env php

Järgmisel teisipäeval ehk 17.05.2016 teeme virtuaalserverite seadistustes kaks PHP versiooniga seotud muudatust, vältimaks millegi katkiminekut ja asjatut debugeerimist väikest hulka kliente puudutav eelteavitus:

PHP Apache mooduli (SAPI) versioon muutub 5.6 > 7.0

Enamus virtuaalservereid kasutab PHPd vaikeseadeks olevas FastCGI režiimis ja endale meelepärase versiooniga, väike hulk on aga valinud PHP Apache mooduli (SAPI) kasutamise. Selles kasutatavat PHP-versiooni oleme uuendanud alati ca pool aastat pärast uue stabiilse versiooni ilmumist ning nüüd on käes hetk minna üle PHP 5.6 pealt PHP 7 peale.

SAPI kasutajatele läks e-postiga ka teavitus viidetega konkreetsetele serveritele, seega kui sa pole kirja saanud, siis ilmselt see muudatus sind otseselt ei puuduta – aga PHP versiooni tõstmine “nii uueks, kui soft kannatab” on mõistlik ka FastCGI kasutajatel. Põhidomeeni versiooni leiab Virtuaalserverite haldusest Veebiserver > Seaded alt, alamdomeenid sealt kõrvalt:

php-versioon

Neil, kellel on PHP režiimiks valitud Apache Module, tasuks aga veenduda oma veebirakenduste toimimises versiooniga 7.0. Seda saab teha näiteks vahetades testiks režiimi 7.0 FastCGI peale (selle jõustumine võtab ca 10 minutit aega). Kui peaks tekkima vajadus jääda kasutama PHP 5.6 FastCGI’d tasub arvestada erinevate failiõigustega – kõik Apache mooduli poolt lisatud pildid, cache jms on mõistagi loodud veebiserveri õigustes ja neile ei pääse kirjutamisõigustes ligi ei FastCGI režiimis kood ega kasutaja FTPga. Õiguste muutmist saab vajadusel küsida info@zone.ee

/usr/bin/env php viidatud versioon muutub 5.2 > 7.0

See on nüüd natuke piinlik – aga ajaloolistel põhjustel on mitmete skriptide poolt universaalseks PHP käivitamiseks kasutatav /usr/bin/env php jäänud viitama versioonile 5.2. Järgmisest teisipäevast ehk 17.05.2016 alates viitab see versioonile 7.0 – ja hakkab edaspidi viitama värskele versioonile sünkroonis SAPIga.

Olles vaadanud läbi serveriteülese grep’i tulemuse (algselt 18tuh rida) paistab, et 99,99% kasutuskohtadest on vabavaralised lahendused või raamistikud – mis eeldatavasti rõõmustavad normaalse versiooni üle. Kui mõni skript peaks siiski vajama vanemat versiooni võib seda kohandada andes ette värskeima sobiliku versiooni, näiteks nii:

/usr/bin/env php56-cli

 

“Teeme ära” koristustalgud sinu (tehtud) veebis – kõik /uus, /vana, /arhiiv ja /newsletter välja!

Fakt: kui su veebi vana versioon on liigutatud alamkataloogi /vana, /old ja uuendamata/turvapaikamata – või kui paned tegemisel oleva ja veel mitte igast nurgast turvatud/uuendatud veebi kataloogi /uus, /new vms – võtavad kurinahad selle varem või hiljem üle.

Pigem varem – ühe turvaintsidendiga tegeledes leidsime näiteks, et uus veeb oli üles pandud /uus alamkataloogi (mõistagi!) mullu 15. septembril ning 25. liigutatud veebi juurkataloogi ehk võetud kasutusele. FTP-logist on näha, et üles laetud veeb oli puhas, liigutamise ajal on seal aga juba sees ühe Hiina reklaamivõrgustiku häkk. 10 päeva, “keegi ei tea, et meil on /uus”. Kes teab, äkki oli adminni parool “test”? Mõni plugin uuendamata? Igatahes leidis selle augu jaanuari lõpus üles järgmine rühmitus ning pani veebi raha teenima.

Talvel koristasin üht teist veebi ja leidsin sealt 6 erinevat WordPress’i, mis paigaldatud viimase 5 aasta jooksul. Ja jupikese ISISe häkist. @martinsookael jagas aga sellist pilti – logides kliendi veebiserverisse leidis ta sealt 8 erinevas kõdunemisfaasis WPd:

Paraku on olemas tööriistad nagu DirBuster (ja selle massrünneteks sobivad analoogid), mille sõnastikud sisaldavad levinud nimekujusid – test.php, phpmyadmin, new, old, dev jne – ning sageli on sellisel viisil avastatud koodi kaudu sisse murdmine lausa tüütult lihtne. Neid veebe krõbistavad nooremhäkkerid hommikukohvi kõrvale, lihtsalt näpuharjutuseks.

Sellest ka “Teeme ära!” üleskutse, mille esimest otsa saab teha ka üldse-mitte-tehniline inimene – tuleta meelde, kas veebiuuenduse ajal on kuhugi vana versioon alles jäetud? Kui meelde ei tule, proovi järgi asukohad stiilis domain.ee/uus, domain.ee/vana, vana.domain.ee … või äkki vedeleb kusagil domain.ee/blogi oma ainsa tervituspostitusega?

Siit edasi võiks FTPga veebiserverisse sisse logida ja vaadata, ega loomehoos arendaja ole mõnda veidi erinevat nimekuju kasutanud – vana-web, vana2, archive jne. Pane kirja, lase veebimeistril igaks juhuks üle vaadata (äkki ikka on millekski vajalik?), siis arhiveerida ja kustutada.

Kui selle käigus hakkab silma aasta 2012 kampaania-maandumisleht, kunagine ise kirjutatud uudiskirjalahendus alamkataloogis /newsletter vms – siis täpselt samasse nimekirja.

Päisepilt ongi ühe täiesti reaalse firma veebiserverist – igati lugupeetav ettevõte, inimesed käivad lipsuga tööl ja büroojuht pakub kohvi kõrvale šokolaadikompvekki. Nende vana uudiskirja-lahenduse kataloogis on süütuna näiv configure.php, mis lähemal vaatlusel võimaldab veebiserverisse uusi faile üles laadida. Ehk teha seda, mida iganes kurinahk teha plaanis.

Jõudu tööle!

PHP 7 on kohal!

php7_300x152

Viimati laulsime siin blogis PHP 7. versioonile hoosiannat siis, kui esimese Release Candidate versiooni oma platvormi lisasime. Täna on mul hea meel teada anda, et PHP 7 on “valmis saanud” ja neil, kel on ühilduv veebileht, hea võimalus see kuni 2x kiiremaks teha.

PHP režiimi vahetamine on võimalik "Minu Zone" haldusliidese vahendusel.
PHP režiimi vahetamine on võimalik “Minu Zone” haldusliidese vahendusel.

PHP 7-ga töötavad juba mitmed sisuhaldussüsteemid ja arendusraamistikud, sealhulgas näiteks WordPress 4.3, Drupal 8, Symfony jt. Hoopis teine lugu võib loomulikult olla erinevate teemade või pluginatega, seetõttu ei maksaks ettevaatlikkust päris unustada. Kannatlikud võiks olla Joomla kasutajad, sest PHP 7 tugi peaks saabuma versiooniga 3.5, mis omakorda ilmub järgmisel nädalal.

Neil, kes oma rakendusi ise ei värskenda ja ei kasuta ka Zone+ abil tehtavaid automaatseid uuendusi, tasub samuti oma järsult tekkinud tegutsemisjanu ohjata. Kui ikka tarkvara versiooninumber on mitu põlvkonda aktuaalsest maas, siis kohe ei maksa PHP režiimi vahetama tormata. Tuleks eelnevalt oma rakendused kaasaega tuua.

Tarkvaraarendajatel tasuks loomulikult heita pilk peale asjadele, mis on muutunud ja leida oma loomingus esinevatele ühilduvusprobleemidele elegantsed lahendused 🙂