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 🙂

Teenuspakettide värskendus

Eile jõustusid Zone Virtuaalserveri uued teenuspaketid, mis tõstavad pakutavate ressursside mahtu 2-5 korda nii senistel kui uutel klientidel – hinnad seejuures ei muutu. Ja nagu televiisoris öeldakse “Aga see ei ole veel kõik!” – juba kaks kuud on kõik Virtuaalserverid kasutanud kiireid SSD-kettaid.

Sellega jõuab finišini aasta kestnud fantastiline kiirendus, mis on läbi uute tehnoloogiate juurutamise loonud ettevõtjatele uusi võimalusi kodulehtede turvalisuse ja kiiruse parandamiseks.

paketivarskendus-2016-05

Pildilt ja hinnakirja lehelt ei hakka silma, aga I pakett on saanud piiramata arvu postkaste ja andmeliiklust, detailide lehelt leiab lisaks suurema koguse (suuremaid) andmebaase ja postiliste.

Tuletame korraks meelde, mis selle spurdi käigus 2015. aastal tehtud sai:

  • tõime HTTPS ühenduse odavamasse teenuspaketti;
  • kasvatasime oluliselt füüsiliste andmesideühenduste kiirust;
  • lisasime PHP 7 toe, mis võimaldas muuta ühilduvad kodulehed kuni 100% kiiremaks;
  • alustasime tasuta Let’s Encrypt TLS/SSL turvasertifikaatide pakkumise katseperioodi;
  • tõime turule soodsa veebilehe turvamonitooringu Nimbusecilt.

Käesoleval aastal pole me lasknud hool raugeda ja mul rõõm kanda ette järgmist:

  • oleme kõigisse Virtuaalservereid teenindavatesse serveritesse lisanud SSD andmekandjad;
  • kuulutasime tasuta Let’s Encrypt TLS/SSL turvasertifikaadid Zone.ee platvormi osaks;
  • lisasime kogu Zone taristusse unikaalsed teenustõkestusrünnete tuvastamise, tõrje, analüüsi ja raporteerimise vahendid;
  • lisasime kõigile HTTPS toega Virtuaalserveri teenuspakettidele HTTP/2 toe.

Virtuaalserveritele eraldatud ressursside kasvatamine on loogiline jätk nendele tegevustele. Teenuspakettide mitmekordistunud parameetritega saab tutvuda Virtuaalserverite lehel.

Ühtlasi kasutan võimalust avalikult kiita meie operatsioonide meeskonda, kes on suutnud paketiuuenduste ootuses meie näljasetele andmekeskusetele sisse sööta tohutu hulga SSD kettaid ja öiseid töötunde.

Respect!

See ei ole kaugeltki kõik - kokku läks Virtuaalservereid majutavatesse serveritesse
Ka see ei olnud kaugeltki kõik – lihtsalt esimene tarne :-)

 

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:

Kuidas see küll juhtuda sai ehk let’s make mistakes

Meie hea naaber Telia sai täna tugeva sotsiaalmeedia-klopperi tänu ühele ebaõnnestunud e-postitusele. “Kuidas see sai juhtuda!!?!” küsivad nördinud kodanikud, spetsialistid ja ilmselt ka Helin…

Aga lubage, ma räägin teile kuidas see saab juhtuda. Mina sain ise kah täna samasuguse jamaga hakkama – ning MailChimpi hirmuhigipisaratega kirja-saatmise-nupu-animatsioon on ilmselt paljudele tuttav:

chimpy-chimp

Stsenaarium on reeglina selline: Meil on mingi e-posti-rakendus, tegime kirja-põhja – noh et oleks ilus ja avaneks ka mobiilis jne. Laadisime üles Excelist imporditud listi kus on kirjas andmeteadlaste poolt välja valitud aadressid, nimed ja isikukohased viited. Testisime enda testkirjega, mis on hoolikalt koostatud katmaks kõiki äärmuslikke juhtumeid (minu nimi on testides stiilis Pëëtõr von McPikknimi Märvüž) – noh täitsa OK tundub. Saatsime pealikule/agentuurile/kliendile kah. Aga kusagil ei ole seda testnuppu, et võta palun 10 random kirjet tegelikust sihtgrupist ja näita mis juhtub.

Juhtub aga see, et kirjapõhja tegija on unustanud panna nime asemele muutuja – või siis on andmeteadlased lisanud Excelisse mediaan-nime välja. Mis iganes see ka poleks.

Mina saatsin välja teadet PHP 7 Apache moodulis ja /usr/bin/env php teemal. Ainus viis see adressaadile arusaadavaks teha tundus lisada konkreetne nimekiri serveritest, mis võivad muudatuse järel probleeme tekitada. Umbes nii:

mail-snippet

(takkajärgi lugedes peaks kiri algama lausega “saada see KOHE veebihaldurile, nõua ASAP reageerimist ja tehtud tööde raportit” olemaks ka turundus- või projektijuhi tasemel rakendatav)

Kuna meil on kick-ass inhouse arendustiim siis saatis @i mulle udupeene JSONi (mittetehniliselt: .json on .csv kuubis) mis võimaldas genereerida vabalt valitud transactional email teenuse (Mandrill, olgu nad neetud) ja umbes 20 rea koodi abil personaliseeritud kirjad. @bb tuvastas nimekirjast mõne kala – ja mina mõned teised kalad. Ahjah, ja oli veel väike palve üks objekti property veidi teise nimega edastada. @i saatis uue JSONi, Done! Proovin saatmist nii- ja naapidi, toimib.

Vajutame punast nuppu – ja kasutajad saavad kirja, kust puuduvad kogu jõupingutuse põhjuseks olevad serverinimed. Abort-abort-abort, pardal on lapsed! (kui tsiteerida multifilmiklassikuid)

Edasine tasklist:

  • katkestada kirjade saatmine
  • lõpetada koosolekul osalemine
  • tuvastada bugi (ei olnud testinud päris uue JSONiga, “kohandasin veits” vana ja eeldasin mida-iganes)
  • eksportida transactional e-posti teenusest enne katkestamist saadetud kirjade aadressid
  • fixida bugi
  • teha uus vabandusega kirja-templiit
  • kohandada saatmine kahele sihtgrupile – pooliku kirja saanud ja ülejäänud
  • testida, veenduda õige templiidi kasutamises
  • umbes x4, sest eelmine x2 ilmselt ei olnud piisav
  • saata parandatud kirjad “poolikutele”
  • testida, umbes 4x
  • saata parandatud kirjad “ülejäänutele”
  • here be dragons

Moraal? Proovime aru saada, miks me vigu teeme. Mina näiteks:

  • Ajasin ülesande keeruliseks (olen siiski veendunud, et konkreetse info andmine e-postis oli õige valik)
  • Testisin lõpuni enne andmeformaadi ja tegelikult kasutatavate andmete saamist (tekkis testi-väsimus, lõplike andmete puhul ei teinud enam täis-testi, sest enamus oli ju läbi testitud juba)
  • Mul ei olnud saatmis-lahenduses funktsiooni “näita mida kavatsed saata”, sest see oli “kõigest prototüüp”

Ma loodan, et Telia jagab oma post-mortemit kah – küllap tegid nad täiesti teistsuguseid vigu. Selliseid, mida mina võiks homme teha, aga võiks ka vältida.

ps. üks mu lemmik-podcaste on Mike Monteiro bande Let’s Make Mistakes.

pps. teavitus-kirja saatmise taustaks olid mõned (igati asjakohased) kommentaarid suunal “debugisin/muretsesin x tundi, põhjuseks oli muudatus/sündmus millest oleksite ju võinud ette teavitada, isegi kui see puudutab 1% kliente” – yep, tehtagu!

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