Miks mu veeb nii aeglane on?
22.02.2007 | GunnarMiks on nii, et ühel heal päeval mu enne nii kiire sait on äkki aeglane ja uimane, et ei jõua ära oodata? Miks osad külastajad ei saa üldse pilti ette? Mis toimub? Selgitan lahkelt, mis põhjusel need nähtused tekivad ja kuidas neid parandada või vältida.
Peamised põhjused
Põhjusi, miks sait äkki uimaseks jääb, on peamiselt kolm:
- veebilehe tarkvara on halvasti kirjutatud,
- veebilehe on paigutatud ebakompetentse teenusepakkuja serverisse,
- veebilehte on saatnud tõusev edu.
Neist peamine põhjus on just see esimene. Kurja juur, ma pakun, 99% juhtumitel. Ebakompetentse serveriteenuse pakkuja juurest saab iga saidi ära kolida ning kui sait pole just eriliste käpardite, keda kahjuks pole vähe, kirjutatud, siis on tegemist ehk tunni või paari küsimusega maksimaalselt. Lehe edukaks muutumine on ainult hea – seda meil ju vaja ongi ja seda me ometi vältima ei hakka. Aga enne kui kolime ja serverit kõiges süüdistame (sest koduka ehitanud firma arvas nii), vaatame otsa tarkvarale, mis meie lehte edasi veab.
Käpardid aktsioonis
Lohakalt või oskamatult kirjutatud tarkvara koormab ka parimat serverit nii, et see muutub aeglaseks ning serveriressurside juurde rentimine pole lahendus – juba järgmise eduka reklaamikampaania käigus on lisa vaja. Elu jooksul on nähtud igasugu musta huumorit tellijatele kasutada antud koodi osas. Kood on olnud küll vaimukas, kuid tellijatest, kes seda õudust kasutama peavad, on mul siiralt kahju. Mõni näide.
Ühe Lõuna-Eesti firma loodud veebisüsteem, mida tellija aastaid kasutas, oli kirjutatud selliselt, et süsteemi oli selle surm juba sisse programmeeritud. Andmebaasiga suhtlemine oli lahendatud sada korda keerukamalt ja ressursinõudlikumalt, kui see vajalik oleks olnud. Kõike oleks saanud teha lühemalt ja palju efektiivsemalt. Ka arendustööde aeg oleks olnud kordi lühem ning see oleks omakorda jätnud rohkem projekti aega sellele, et leht külastajatele atraktiivsemaks teha. Selle süsteemi surm oli orienteeruvalt 4000-5000 rida ühes põhitabelitest. See on kaduvväike arv tänapäevaste edukate veebide andmebaaside suuruse juures.
Ühel ürituste korraldajal oli näiteks suure vaevaga ehitatud süsteem, mille juures oli kokku hoitud iga viimase kopika pealt. Tulemuseks oli lähtekood, mis nägi välja nagu oleks keegi selle oksendanud, mitte kirjutanud. Selle koodi parandamine ja vigade otsimise oli paras tegemine, mis võttis kõvasti aega. Turvaauke oli seal nii palju, et keskmine 16 aastane script kiddie oleks selle saidi jäädavalt koos andmebaasidega maha murdnud tunni või paari jooksul maksimaalselt.´Sellest, milline korralagedus ja seapesa andmebaasist vastu vaatas, ei hakkama parem pajatama.
Muide, neid teostajaid, kes selliseid asju ausa näoga oma tellijatele pakuvad, pole vähe. Nende peamine ühine nimetaja on odav hind. See siis tähendab seda, et veebileht koos disaini ja kõige muuga läheb maksma praegusel hetkel alla 25 000 krooni. Ja 25 000 on, muide, kvaliteetse täisteenuse pakkumise juures alla omahinna piir juba. Jutt sellest, et kui ikka tahta, siis leiab teostaja jne, on kerge tulema, kuid motivatsiooni kaotanud teostaja välja vahetamisele kulub raha oma kaks korda rohkem, kui sisse arvestada ka vahetamisele kulunud aeg.
Seega odavalt tellides tuleb enda käest küsida järgmist: “Kas ma olen nii rikas, et osta odavaid asju?”
Kuidas parandada jõudlust?
Jõudluse parandamiseks on mitmeid võimalusi. Enamasti aitab lähtekoodi ja andmebaasipäringute optimeerimine. Kui see on tehtud ja enam paremaks ilma uut ja paremat süsteemi tellimata olukord ei muutu, siis jääb üle veel sisu puhverdamine, mis tavaliselt tõstab lehekülje jõudlust tuhandeid kordi.
Andmebaasipäringute optimeerimine
Andmebaasipäringuid on võimalik kirjutada tihti palju efektiivsemalt. On olemas töövahendid, mis aitavad jälgida päringute täitmist – millisest tabelist kui palju ridu päringutesse kaasatakse, palju ridu neist on vaja läbi käia, kuidas ridu otsitakse jne.
Enamasti ei kipu odavad käpardid neid vahendeid kasutama ning olles testinud kodulehekülge käputäie näitlike andmetega, antakse lehekülg tellijale üle. Kuid probleemid päringutega ilmnevad just suuremate andmemahtude ja suuremate koormuste juures. Ja see teave odava firma know-how’s endale enamasti kohta ei leia. Ja teinekord paraneb jõudlus hüppeliselt, kui andmebaasi tabelitele lisada unustusehõlma vajunud asjad – indeksid (Kuidas indekseerida andmebaasi tabeleid, MySQL: Indeksid ja otsingud arvulistest vahemikest).
Lähtekoodi optimeerimine
Teine koht, kus tihti annab maailma parandada, on süsteemi lähtekood. Kui lähtekood on kirjutatud halvasti, siis kannatab ka jõudlus. Näiteks eelmainitud Tartu kunnide koodis oli andmebaasipäringuid ühe pöördumise kohta oma 20 korda rohkem kui vajalik. Seetõttu pidi süsteemi lähtekood tegema roppu moodi tööd, et andmebaasist tulnud töötlemata info külastajale esitamiseks söödavale kujule saada. Veel kord – sama koodi oleks saanud kirjutada kolm korda lühema ajakuluga, aga 1000 korda efektiivsema jõudluse osas.
Sisu puhverdamine
Kui eelmised kaks lahendust aitavad meid käpardite juhul, siis viimane lahendus on abiks alati. Ka heades süsteemides võib olla külastajale sisu esitamine paras tegemine. Sisu aga ei muutu meil iga minut. Tavalistel kodukatel muutub info heal juhul kuus korra või paar. Siit jõuame tulemuseni, et üle paari korra kuus pole vaja sisulehtekülgi uuesti genereerida, sest kui neid kuidagi hoida sellisel kujul, nagu neid külastajale näidatakse, siis saaks ju külastajale juba valmis lehekülgi ette anda, kui midagi muutunud pole.
See ongi puhverdamise mõte. Salvestame maha iga pöördumise käesoleva seisu ning näitame seda igale järgmisele tulijale juba maha salvestatud kujul, et ei peaks uuesti sama lehekülge genereerima. Kui midagi muutub, siis kustutame vastavad leheküljed puhvrist maha ja juba järgmine pöördumine genereerib valmis uue seisu, mis automaatselt puhvrisse läheb.
Meie tõstsime sel teel DT blogi jõudlust 1000 korda.