Amsterdamis majutatud serverid kolivad uude andmekeskusesse

Neljapäeva, 26. jaanuari varahommikul kolime Amsterdamis majutatud Pilve- ja Virtuaalserverid uude andmekeskusesse.

Kolimisega kaasneb katkestus kell 01-05 (Eesti aja järgi), kliendid keda see mõjutab said nädal tagasi e-postile ka vastava eelteavituse.

Kuna meie seni kasutatud Amsterdami andmekeskus hakkas kitsaks jääma, oleme umbes pool aastat plaaninud oma serverite kolimist uude andmekeskusesse.

Toide, võrguühendused ning osa võrguseadmetest on seal juba kohal ja testitud, 26. jaanuari varahommikul liiguvad ühest majast teise ka serverid, mida kasutavad Pilveserver PRO SSD kliendid, aga samuti oma asukohaks Amsterdami valinud Pilveserver VPS ja Virutaalserverite kliendid.

Kolimisega kaasneb ca 4h katkestus – aga nagu timelapse-videost näha, oleme me seda juba oluliselt suurema hulga serveritega harjutanud:

Zone teenuste olekut saab reaalajas jälgida status.zone.eu, samast saab ka tellida e-postile teavituse intsidentide kohta.

Uus asukoht Euroopa ühes kaasaegsemas andmekeskuses (Equinix AM6) tõstab meie süsteemide töökindlust, tagades kõrgendatud nõuetele vastavad toite- ja võrgulahendused, võimsama kliimatehnika ja kõrgema turvalisuse. Andmekeskuse sertifitseeringud hõlmavad nii ISAE 3402, ISO27001, ISO 140001, ISO 50001 kui ka PCI DSS standardeid. Mitmekordistub ka meie kohapealse andmesidevõrgu ühenduskiirus.

Kuna uues andmekeskuses avaneb meil võimalus paindlikumalt muuta olemasolevaid ning luua uusi teenuseid, siis oleme huvitatud ka teie ettepanekutest, soovidest ja tagasisidest – muuhulgas on uues kohas juba paigas esimesed Nutikad Privaatserverid.

Node.js veebirakendused nüüd Zone virtuaalserveris – kauba peale PM2, mod_proxy ja portide suunamine

Võimalus käsurealt Node.js rakenduste käivitamiseks tekkis Zone virtuaalserverites umbes aasta tagasi koos SSH-ligipääsu lubamisega – aga kuna kogu veebiliikluse võttis enda peale Apache, puudus võimalus neile internetist ligi pääseda. Ekstreemsemad kasutajad aga leidsid omal käel lahendusi – passiivse FTP jaoks on mingi pordivahemik ikkagi avatud, mod_proxy abil saab liiklust suunata ja cron’i saab panna skripti, mis tagab rakenduse käigushoidmise. Katsetamiseks “intellektuaalselt huvitav nipp”, aga selle abil kaugele ei purjeta.

Kui aga hakkasime kasutajate huvist tulenevalt Node.js veebirakenduste jaoks head lahendust otsima – algselt plaanitud kiire nädalavahetuse-häkatonina – jõudsime oluliselt laiemat kasutust omavate komponentideni virtuaalserveri halduses:

  • Erinevate rakenduste seadistamise ja serveri restardil automaatse käivitamise võimalus (seda kasutab juba meie Redis-vahemälu lahendus.)
  • PM2 protsessihaldur, mille abil saab käivitada ja hallata Node.js rakendusi (aga ka näiteks PHP või shelli skripte).
  • Apache mod_proxy seadistus, mis võimaldab suunata veebiliikluse (ehk port 80 ja HTTPS puhul ka 443) kasutaja rakenduse poolt kuulatavasse porti.
  • Portide suunamine (port forwarding), mis võimaldab virtuaalserverile eraldatud IP kasutamisel avada ja suunata väliseid porte (>1024) ja sobib mh WebSocket’it implementeerivate rakenduste jaoks.

Kuidas seda kõike kohe omal nahal järgi proovida?

Sellest videost leiab “Hello world” rakenduse käivitamise näite – keerulisemad juhud nagu tuntumate raamistike kasutamine, Websockets’i tugi jms saavad oma videoõpetused veidi hiljem.

Meetod 1 – mod_proxy

Alustaks ühest väga lihtsast Node.js “Hello World!” rakendusest – teen testimise tarbeks virtuaalserveri halduses uue alamdomeeni node.miljonivaade.eu ja määran sinna lisandunud parameetri mod_proxy sihtpordi väärtuseks 8080. Selle tulemusel hakkab Apache toimima reverse proxy‘na ehk kõik porti 80 tulevad HTTP päringud suunatakse edasi localhost’i porti 8080.

node-subdomain-dip

Kui domeenil või alamdomeenil on lubatud ka HTTPS, saab selle seadistada samamoodi (või kasutada HTTP seadeid) – seejuures on oluline arvestada, et nagu reverse proxy puhul sageli tavaks, toimub turvaline SSL ühendus kasutaja ja Apache vahel, sealt edasi Node.js rakenduseni liigub lahtine HTTP päring.

Seejärel laen üles app.js koodi (asukohaks ei pea olema alamdomeeni kodukataloog):

var http = require("http");

http.createServer(function (request, response) {
 response.writeHead(200, {'Content-Type': 'text/plain'});
 response.end('Hello World! I am a Node.js app :-)\n');
}).listen(8080);

Nagu näha, tekitab see porti 8080 kuulava veebiserveri ning tagamaks selle käivitamise ka pärast tõrget või füüsilise serveri restarti, on vaja see lisada PM2 protsessihaldurisse (Veebiserver › Node.js ja PM2):

node-add-app

Rakendusi saab lisada nii .js kui PM2 rakenduse deklaratsiooni .json või .yml failina, mis lubab seadistada kõiki PM2 parameetreid, käivitada korraga mitut rakendust jpm.

Kasutada olev summaarne mälukogus sõltub virtuaalserveri paketist ning seda saab jagada mitme rakenduse vahel omal äranägemisel.

Protsessi lisamise järel võib minna kuni 3 minutit selle tegeliku käivitumiseni, olekut näeb lehe uuestilaadimisel (tulevikus loodetavasti ka ilma laadimiseta). Ja kui see on “Käivitatud”, siis võib testima asuda:

hello-there

Edaspidi saab rakendust samast kohast virtuaalserveri halduses peatada, muuta, kustutada ja restartida.

Meetod 2 – port forwarding

Selle lihtsa mod_proxy lahenduse puhul ei toimi aga WebSocket ühendused, nende jaoks oleks vaja kogu välisesse porti tulev liiklus rakendusele suunata.

Selleks lisasime virtuaalserveri haldusesse pordi suunamise võimaluse – tõsi, selle kasutamiseks on vaja eraldi IP-aadressi, mida pakub Pakett III (üks aadress sisaldub hinnas, selle aktiveerimiseks tuleb saata kiri klienditoele). Olgu siinkohal mainitud, et portide suunamine kasutamine torrenti- või mänguserveri, proxy vms teenuse jaoks on rangelt keelatud seoses võimalike juriidiliste ja serveri koormuse küsimustega. Kui kahtled plaanitava kasutuse lubatavuses, siis kirjuta palun meie kasutajatoele ning kirjelda oma rakendust ja eeldatavat kasutajate hulka.

Demoks sobib kenasti socket.io näidis-chat, mille paigaldan serveris vabalt valitud asukohta, tehes SSH abil vajalikud npm install’id ja seadistan seejärel PM2 abil käivitatavaks:

node-app-list

Kui nüüd ülevalpool olevat alamdomeeni seadistust uuesti vaadata, hakkab loodetavasti silma, et seal on alamdomeenile eraldi IP-aadress juba määratud (217.146.71.171) ning mul pole vaja teha muud, kui lisada vastav pordi suunamine näidis-chatis kasutusel oleva port 3000 jaoks:

node-port-forward

Pordi suunamise rakendumine võib aega võtta kuni 10 minutit. Selle ajaga jõuab teha väikse kohvipausi ja minnes seejärel aadressile node.miljonivaade.eu:3000 … on tulemuseks toimiv chat:

weirdo-chat

Mis edasi?

Edasi võiks proovida näiteks rakenduse käivitamist mitte .js, vaid .json abil – kui lisada sama “Hello, World” rakenduse kataloogi selline app.json, muuta vastavalt PM2 seadistuses rakenduse asukoht ja see taaskäivitada …

{
 "apps" : [{
 "name" : "hello-world",
 "script" : "app.js",
 "watch" : true,
 "cwd" : "/data02/virt33390/domeenid/www.miljonivaade.eu/nodetest",
 }]
}

… siis hakkab PM2 jälgima parameeteriga cwd määratud kataloogis toimuvaid failimuutusi ja restardib rakenduse automaatselt. Mugav harjutamise või arenduse käigus, aga ilmselt tasuks production’is mitte peale unustada. Samuti “te ei usu, mis juhtub”, kui watch’iga rakendus midagi ise enda kataloogi kirjutab, näiteks logifaili: rakendus ‘retarditakse’ ehk PM2 proovib kümmekond korda restartida ja loeb siis asja lootusetuks.

Kui PM2 käivitusprotsessis miski nihu läheb – või on soov katsetada ilma virtuaalserveri haldust mängu segamata – siis saab sellele ligi ka SSH abil. Olulisemad käsud leiab PM2 spikrist, samas on kirjas ka kataloogistruktuur, mille PM2 tekitab virtuaalserveri kodukataloogi alla (sealt leiab nii rakenduste kui PM2 logid).

pm2-list

Ja kuna PM2 on tehtud Keymetrics’i poolt … siis saab ühe käsuga lisada ka nende monitooringu (lihtsam vaade tasuta, paremad tööriistad ja teavitused raha eest):

pm2-keymetrics

Ja edasi edasi?

Uuri, proovi, katseta – ilmselt on paslik seda lahendust hetkel beetaks lugeda ning anda meile teada sellest, mis ei toimi oodatud viisil, vajaks muutmist või lisamist. Või siis mis toimib väga hästi ja lahendab tegelikke probleeme 🙂

Teada võib anda otse siinsamas kommentaari-sabas, meie FB-lehel, kirjutades peeter@zone.ee või liitudes Skype grupi-chatiga.

Korduma Kippuvad Küsimused

Mis Node.js versiooni kasutate? Hetkel on selleks 6.3.0, edaspidi hakkame hoidma kõiki servereid värskeima LTS peal.

Palju mälu kasutada saab? Sõltub paketist – I, II ja III vastavalt 512MB, 768MB ja 1024MB. Mälupiir on hetkel soft limit ehk toimub “proaktiivne monitooring” ja piiritundetud kasutajad kutsutakse küberneetiliselt korrale.

Ma saan selle PM2 ju ise kah SSHs käima tõmmata? Tõsi, aga siis ei ole tagatud rakenduste taaskäivitumine serveri restardi puhul.

Miks te PM2 valisite, xyz on palju parem? Sellepärast, et.

Kas Node.js binaarsed moodulid ei olegi toetatud? Kuna oleme otsustanud kompilaatoreid virtuaalserverites mitte pakkuda, puudub ka võimalus binaarseid mooduleid paigaldamise käigus kompileerida. Meie hinnangul saab suurem osa Node.js rakendustest ilma hakkama.

Rohkem küsimusi ei ole? Hakkame siis tööle!
(kui on küsimusi – võid liituda Skype grupi-chatiga)

Redis annab professionaali veebile vunki

 

Redis logo

Jätkame kodulehe kiiruse parandamist võimaldavate vahendite lisamist klientide tööriistakohvrisse. Seekord on tegu maiuspalaga professionaalidele, sest Virtuaalserveri klientidele on saadaval Redis, maailma üks populaarsemaid NoSQL andmebaasimootoreid ja värskendavalt kirbe juurvilja nimekaim.

Redis võimaldab rakendusele luua täielikult serveri põhimälus asuva fantastiliselt kiire puhvri ehk ‘cache’, milles võib hoida objekte, mida on veebilehe kuvamiseks tihti vaja.

TL;DR – Zone lisab Redise toe, et saaksid oma e-poe või kodulehe kiiremaks teha. Redise lisamiseks Virtuaalserverisse on vaja klikkida vaid ühel nupul, juhendi selle leidmiseks leiad käesoleva postituse lõpuosast.

Redis on kiire, paindlik ja stabiilne tarkvara. Veebirakenduste kontekstis on selle peamised kasutuslood seotud võimalusega andmeid ülikiiresti kirjutada ja lugeda, mis on eriti oluline e-kaubanduse kontekstis.

Veel mõnd aega tagasi kasutati sarnaseks funktsiooniks Memcached nimelist jubinat. Kuna Redisel on viimase ees palju olulisi eeliseid, siis on kaalukauss kogu maailmas kaldunud viimase, kui kaasaegse ja täisverelise NoSQL andmebaasimootori kasuks.

Redise kasutamist toetavad läbi sisseehitatud toe või laienduste paljud populaarsed sisuhaldusvahendid ning e-kaubanduse platvormid nagu näiteks WordPress, Drupal, Magento jt. Kuna Redis on professionaali tööriist, siis ei pruugi selle kasutuselevõtt kõikidel platvormidel olla nii lihtsaks tehtud, kui näiteks Magentos.

Veebirakendused, mis Redist toetavad hoiavad seal tihti:

  • kasutaja sessiooni;
  • ostukorvi;
  • külastusajalugu;
  • ostusoovitusi;
  • tootekataloogi andmed;
  • analüütikat;
    jms.

Redise tugi on Virtuaalserveri klientidele olemas alates teenuspaketist II. Mälu on selles Redisele eraldatud 256 MB ja III paketis 512 MB.

Redise leiab “Minu Zone” keskkonnas asuvas Virtuaalserveri juhtpaneelis, alajaotuses “Andmebaasid/kasutajad”:

Mõne PHP rakenduse puhul võib olla vajalik ka Redise PHP laienduse sisse lülitamine:

activate_redis_php

Redis ja muud kasutuslood

Redisel on teisigi populaarseid kasutuslugusid, mis seotud kvantitatiivsete andmete kogumise, mõõtmise ja töötlemisega, aga ka kommunikatsioonikanalite loomisega erinevate süsteemide vahel (http://redis.io/topics/pubsub). Need erinevad aga puhverdamisest peamiselt selles osas, et nõuavad ka Redise andmete kettale salvestamise võimalust (‘persistence’), mida me hetkel veel ei paku.

Kui sul on huvi ‘persistence’ kasutamise vastu, sest sul on ägedaid mõtteid, kuidas tahaksid seda kasutada, siis anna meile neist teada, et saaksime Redise toe arendamise järgmises etapis sellega arvestada.

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: