18.01.2021 katkestuse post-mortem

Esmaspäeva, 18. jaanuari õhtul lõpetas töö üks meie võrguseade, täpsemalt kommutaator ehk switch, mille kaudu käib mitmete serverite võrguühendus.

Tegemist oli seadmega, milles riskialtid komponendid dubleeritud, kuid mille riknemisi siiski esineb. Tavapäraselt oleme võrguseadme väljavahetamise ajakuluks arvestanud umbes 1 tunni. Selliste seadmete korralise väljavahetamise tsükkel on meil 5 aastat, uued täielikult dubleeritud seadmed olid seadistamise lõppfaasis.

Katkestus algas kell 17:15 ja mõjutas ca 40% Virtuaalserveritest ning 1/3 tavapärasest veebipäringute arvust. Klientide muud teenused nagu e-post, nimeserverid, ZoneCloud toimisid normaalselt.

Paraku ilmnes võrguseadme vahetamise järel, et tavapärase liiklusmahu korral kahaneb võrgukiirus olematuks.

Järgnes veaotsing, mille käigus prooviti läbi erinevad vea-hüpoteesid, paigaldati järgmine varuseade ja valmistuti ka võrgusegmendi üleviimiseks erinevale tehnoloogiale. Lõpuks tuvastati probleemina kommutaatori tarkvara viga, mis ilmnes reaalse koormuse tekkimisel ning mida ei olnud võimalik testkeskkonnas tuvastada. Probleemi lahendas vanema tarkvaraversiooni kasutuselevõtt, kõigi teenuste töö oli lõplikult taastunud kella 00:50ks.

Mida me teeme teenuste tõrkekindluse parandamiseks?

Kuna kõik Virtuaalservereid teenindavad serverid on meil test-rakenduse tasemel välises monitooringus jälgitavad, siis teame, et nende käideldavusnäitaja, milles sisalduvad ka korralised hooldused, on aasta lõikes 99,96-99,98%. Käesoleva katkestuse järel on mõjutatud serverite aastane näitaja tasemel 99,85%-99,89%. Meie eesmärk on alati olnud hoida oma teenustase koos hooldusakende arvestusega üle 99,9% käideldavusel ja hooldusaknaid välja jättes võimalikult lähedal 100%-le.

Nagu mainitud oli meil ettevalmistamisel võrguseadmete väljavahetamine ja täielik dubleerimine eesmärgiga selliseid riske maandada. Viime selle lõpuni lähinädalatel ja mõistagi öisel ajal, täpsest ajast teavitame kliente e-kirjaga.

Palume vabandust rikke põhjustatud ebamugavuste pärast ja panustame aastal 2021 veelgi enam sellesse, et kõik Zone teenused oleksid võrdselt töökindlad, ajaga kaasas käivad ja turvalised.

Ja kindlasti tänud neile, kes meie tehnikute tegevusele sotsiaalmeedias kaasa elasid – püüame olla oma tegevustes võimalikult läbipaistvad, kuvades nii tõrkeid kui plaanitud hooldusi zone.ee esilehel koos viitega status.zone.eu lehele, kust huvilistel on võimalik tellida ka teavitused e-postile. Samuti võite alati kindlad olla, et Zone süsteemid on 24/7/365 monitooritud ning sõltumata nädalapäevast või kellaajast ning riketega tegeletakse, kuni need on lõplikult lahendatud.

Tehniline taust

Tegemist oli võrgusegmendiga, kus oleme viis aastat kasutanud SDN (Software Defined Networking ehk programmeeritav võrgustus) tehnoloogiat, mis lahutab võrgu riistvara ja tarkvara üksteisest sõltumatumaks. Lihtsustades tähendab see, et kasutame Linuxil põhinevaid võrguseadmeid maailma juhtivatelt tootjatelt, mis on oma iseloomult suhteliselt lihtsad ja robustsed meie spetsialistidele seadistada, hallata jne.

Samuti on meil korraliste riistvarauuenduste käigus võimalik valida parim lahendus, olemata seotud ühe tarnijaga. Nagu eespool mainitud, olime ühte sellist vahetust just ette valmistamas, uued seadmekapid olid ette valmistatud ning lähinädalatel plaanis serverite üleviimine. Tavapäraselt olid nii põhi- kui varuseadmed seadistatud kasutama tarkvara värskeimat stabiilset versiooni ning testitud.

Üks selline varuseade võeti kasutusele ning alglaadimise järel tundus kõik andmekeskuses olevatele tehnikutele toimivat, aga kaughaldust tegeval meeskonnal oli probleeme ligipääsuga serveritele. ping toimis kenasti, aga ssh oli probleemne, staatiline sait HTTP peal toimis aga HTTPS keeldus kätlemast, andmebaasiserveriga ei saadud ühendust jne.

Kogu võrguseadmete konfiguratsioon käidi ridahaaval läbi, et tuvastada erisusi kõrval töötavate seadmetega. Katsetati kõiki võimatuid ja võimalikke riistvaraga seotud teooriaid alates AOC (Active Optical Cable) kaabliriketest, lõpetades võimalike anomaaliateni DDoS kaitses jne.

Vea tuvastamise protsessi käigus toodi meie teisest andmekeskusest kohale kolmas sarnane võrguseade välistamaks võimalust, et esimene asendusseade on vigane. Jällegi, läbiti tavapärane protseduur selle seadistamiseks ja paigaldamiseks, kuid kahjuks jõuti kõikide muudatuste tulemusena täpselt samasse punkti välja. Kõik töötab, aga seadmesse sisenedes kahaneb andmeside olematuks – nagu autol rakenduks puhtal sirgel teel veojõukontoll.

Lõpuks jõudsime tegeliku juurprobleemini. Mis nii kurioosne kui see ei ole, oli seotud selle võrguseadme eesootava asendusega. Nagu öeldud, siis SDN puhul on tihti kasutusel arhitektuur, kus võrgu riistvara on ühelt tootjalt (nö “white box”) ja selle nutikus tuleb Linux operatsioonil põhineva tarkuse kaudu mujalt. Selgus, et meie tehnikud kasutasid rikkis võrguseadmele asenduse paigaldamisel Linuxi versiooni, mida nad olid juba kasutanud uute võrguseadmete ettevalmistamisel. See oli aga mõne väljalaske võrra uuem, kui see mis varasemasse seadmesse oli paigaldatud. Uus tarkvaraversioon sisaldas seni täpselt tuvastamata viga ning probleem lahenes vanema tarkvaraversiooni paigaldamisega.

Järgmisel päeval suutsid tehnikud laboritingimustes probleemi reprodutseerida. Me ei tea veel milline tarkvara “bugi” või ”uus featuur” täpselt seda põhjustas, aga ASIC erikiipidel toimuv superkiire TCP/IP pakettide edastamine lülitati seadmes välja ja nende edastamine läks üle CPU-le ehk protsessorile, mis andmeside kontekstis on võrgu jõudlusele sisuliselt surmahoop. Paraku ei täheldanud me sedapuhku ka CPU koormusnäitajate märkimisväärset tõusu. Nimelt on selles samas tarkvaras ka loogika, mis piirab protsessorile edastatavate pakettide arvu ülekoormust ennetavalt ära.

Takkajärgi sündmuste ahelat läbi vaadates tundub kõik muidugi lihtne, aga reaal-ajas tähendas see paljudele seda, et esmaspäeval tuli tööpäevale teine ja keskmisest stressirohkem otsa. Tegutseme edasi selle nimel, et 24/7/365 käideldavus oleks saavutatav rahulikult 9st 17ni riske maandades :.)

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 meie slack.zone.eu kanaliga.

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 🙂