Miks mu veeb aeglane on? Vaata BlackFire abil järgi!

Kuidas aga see kitsaskoht üles leida?

Esimene samm: väline monitooring

Minul on kombeks kõiki jõudlusprobleeme asuda lahendama kõige lihtsamast veebilehe monitooringust: pingdom.com teeb iga minut veebipäringu, joonistab vastamiseks kulunud ajast graafiku ning saadab e-postile teavituse, kui saab vea või vastus liiga kaua aega võtab*.

Kuvades lehtede või toodete lisandumisel kuude jooksul aeglasemaks muutuvat rakendust, võib tulemus olla näiteks selline:

Suur hulk probleeme on aga “jalutavad” – ehk enamiku ajast töötab veeb kiiresti, mingite sündmuste koosmõjul läheb aga aeglaseks:

Teine samm: mis toimub koodis?

Veebirakendustel on probleemide leidmiseks sageli omad lisad või pluginad, nt WordPressi puhul aitab Query Monitor kiiresti üles leida probleemsed andmebaasipäringud.

Visuaalsema pildi toimuvast annab aga BlackFire, mille PHP-laienduse saab Zone Virtuaalserveri puhul hõlpsalt sisse lülitada ja oma BlackFire kontoga siduda, kohaks Veebiserver » Peadomeeni Seaded (või Alamdomeenid) » Muuda » PHP laiendused:

Võrreldes rakenduste pidevaks monitooringuks mõeldud teenustega (nt NewRelic, mille saab meil muideks samast kohast aktiveerida) on BlackFire probleemide tuvastamise rollis oluliselt mõistlikuma hinnastusega – 19,90€ eest kuus saab endale “profileerija” konto, mida arendaja saab vabalt kasutada kõigi oma töös olevate (või ootamatult sisse sadavate) projektide puhul.

Kõige lihtsam viis profileerimiseks on Chrome laiendus – kui serveri poolel seadistus tehtud, lähed huvipakkuvale (alam)lehele ja vajutad nuppu. BlackFire kogub serveri poolel inffi ja saadab selle oma teenusesse, kus saad tulemust soovi korral teiste asjaosalistega jagada, näiteks nii.

Kuidas aga saadud tulemust lahti mõtestada? Võtame (anonüümselt) ette mõned reaalse elu juhtumid ja vaatame, kuidas probleemi otsimine käib. Alustuseks üks veeb, mis võiks vabalt olla Pingdomi juures mainitud “jalutava probleemi” graafikul kuvatu.

Probleem 1: veeb ootab välise päringu taga

Esimese asjana vaatan ma ülemist rida. Sedapuhku torkab kohe silma pea 3 sekundit, mis kulunud http-päringutele mingite väliste süsteemide pihta. Probleeme tekitav funktsioon on parempoolsel graafil kenasti punane ja sellele klikkides kuvatakse ka lisa-infot – kes teda kutsus, mida funktsioon tegi ja kelle poole edasi pöördus.

Sedapuhku kulub igal lehekuvamisel aega välise CRM-teenuse peale, kust kahel korral http-päringuga mingit infot laetakse. On seda infot ikka hädasti vaja? Miks tehakse kaks päringut? Miks see teenus aeglane on? Kas oleks võimalik vastust puhverdada? Kas selle päringu võiks teha kasutaja brauser pärast ülejäänud lehesisu laadimist?

3-sekundiline lehelaadimine on aga vaid väike osa probleemist – kui seda teeb server, kuhu külastajaid satub rohkem tulema (õnnestunud kampaania?), saab serveris lubatud PHP-protsesside arv varsti täis ning järgmised päringud peavad ootama eelmiste lõppemist.

Tehes käsurealt top avaneb siis selline pilt:

Sellised PHP käivitamise taga ootavad päringud näevad muideks BlackFire’is välja täiesti normaalsete sekundiliste vastustena – sest kuniks veebiserver (Apache) ootab vaba PHPd, ei ole ju ka mingit aega mõõta…

Ja kui PHPs tehtava päringu puhul on jäänud mõistliku pikkusega timeout seadistamata ning mõne lehe kuvamine hoiab PHP protsessi kinni 30 sekundit … siis pole kampaaniat vajagi. Probleemi avastamise teeb raskemaks see, kui aegavõtva päringu põhjustab suvaline alamleht (mida otsimootor parasjagu indekseerida proovib).

See on täpselt see probleem, mida tähistab üleval Pingdomi graafikul kell 14-15 algav küür. “Meie veebil” polnud häda midagi, aga üks teine veebiserver (või selle netiühendus) käis käntsu…

Probleem 2: meeletult SQL-päringuid

Tuhatkond andmebaasi-päringut pole küll mingi rekord – mulle meenub esileht, mille kuvamiseks tehti 12000 – aga väikseks rehkenduseks sobib hästi:

Oletame, et üks kiire andmebaasipäring võtab 2 millisekundit. Kui neid teha 1350 tükki, siis kulub sellega sahmerdamiseks … ligemale 3 sekundit. Lihtne soovitus – pea meeles,  et tuhandega korrutades saab millisekundist sekund.

Ülaloleval pildil on Magento otsingulehe kuvamine ning kuna see pole puhverdatud, siis on suur hulk päringuid paratamatu. Aga kui sa paned kampaania landing‘uks otsingulehe, siis võib see lisakoormus osutuda probleemseks.

Päris ilma cache’ta Magento 1.x kategoorialehe puhul on pilt selline, jõud kulub hulgast XMLidest konfiguratsiooni kokku ehitamisele:

Probleem 3: laeme kogu tabeli mällu ja siis sõõlame seda PHPs

Järgmine probleem on ilmselt esimese Pingdomi graafiku pideva kasvu taga – andmebaasi vastu tehakse küll vähe päringuid, aga küsitakse terve tabeli sisu ning siis asutakse seda PHPs läbi lappama. Näiteks selleks, et kuvada kategoorialehel 20tuh tootest järgmised 10:

Ole inime, ära tapa PHPd tööga, seda saab teha ka elektriga … st SQLiga. Kategooria lappamiseks sobiks nt LIMIT 10 OFFSET 1200.

Probleem 4: imetabased (ent indekseerimata) metaväljad ja andmebaas kui prügimägi

WordPressi puhul on tüüpilisemaks probleemiks pluginad, mis hoiavad oma andmeid post_meta tabelis ning teevad selle pihta imetabaseid päringuid. TOP-3 võiks olla selline:

• Advanced Custom Fields – mugav viis lisada postitusele lisainfot või kindla vormindusega sisublokke. Aga selle peale ei tasu ehitada suuremat andmebaasilahendust, mis teeb otsinguid meta-väljade sisu kasutades. Mis ei ole vaikimis teps mitte indekseeritud (indeksi lisamine parandab olukorda mõnevõrra, aga mistahes andmetüüpide tekstiväljas hoidmine ei ole parim strateegia muretuks pensionipõlveks)
• WooCommerce – aga mis oleks, kui me paneks kõik toodete, tellimuste jne kohta käiva informatsiooni nendesse metaväljadesse? Yep, that’s WooCommerce. Jube mõnus tööriist sajakonna tootega poe jaoks, aga pane ennast korraks andmebaasi mootori olukorda – kui kogu su 10tuh tootega pood asub laoruumis mustades prügikottides. “Tahaks M suurust punaseid särke mis ei maksa rohkem kui 12€” – “Juba jooksen!” – “[piinlikult pikk paus, kuulda on ähkimist, kohmitsemist ja kilekottide rebenemist]”.
• WPML – minu ammune lemmik mitmekeelse veebi tegemiseks, hea mugav lehti ja postitusi tõlkida. Aga WordPressil on olemas väga normaalne .po/.mo failidega tõlkimise tugi, mille asendamiseks pakub WPML mugavusvõimalust need andmebaasi migreerida. Sa püha püss, kus kiirus kukub! Ja kui nüüd paneks juurde WooCommerce metaväljades oleva sisu tõlkimise … (me soovitame “lihtsaks rauaga tapmise lahenduseks” Nutikat Privaatserverit, sest siis püsib kogu see tarbetult keeruline andmebaasimudru kenasti mälus :-).

Mul ei ole hetkel head näite-pilti, lisan kui leian. Või kui sina saadad 🙂

Probleem 5 – visuaalsed jms lehe-ehitajad

BlackFire’s on lisaks funktsiooni-graafile olemas ka väga ilus ajajoon, mis annab aja kulumisest ning funktsioonide seostest isegi parema pildi:

See on üks veidi keerulisem alamleht, kus kuvati 8 … ütleme, et “toodet” ning iga ühe kohta nimistut sellega seotud postitustest. Nimistu kuvamine oli tehtud pluginaga, mis lubas lisada lehele PHP-koodi sisaldava shortcode’i ning koodis oli lihtne get_posts() ja foreach tsükkel … mida jooksutati eval() abil. Tuleb välja, et selline tsükkel on vääääääga aeglane, probleemi lahendab lehe-templiit … või siis oma shortcode, mis võtab parameetriks toote ja siis kuvab mida-vaja.

Teine esile toodud aega kulutav element on mitme-tasemelise menüü ehitamine – WordPressi puhul on ka menüü sisuliselt hulk eritüübilisi postitusi ja neist hierarhia kokkuehitamine misiganes põhjusel aeglane. Kuna menüü sisu eriti sageli ei muutu, siis ma prooviks selle ära cacheda.

* * *

Kui jutt huvi tekitas, siis proovi ise järgi – Zone Virtuaalserveri peal katsetades ei nõua isegi paigaldamine mingeid eriteadmisi. Mina alustasin BlackFire õppimist tasuta Hack plan’iga, siis proovisin Premiumi trialit, aga jäin lõpuks Profiler’i peale pidama.

Send moare freak bugs 🙂