Szerencsére nemrég újrakezdődött a TechTalk sorozat nálunk, amikor kéthetente meghívnak egy külsős előadót, hogy beszéljen kb. egy órán keresztül egy témáról. Most Bobby Johnson-on volt a sor, aki az Interana egyik alapítója és jelenleg technikai igazgatója, korábban azonban évekig a Facebok infrastruktúra részlegének a vezetője volt. Most arról beszélt nekünk, hogy általában véve hogyan lehet javítani egy rendszer teljesítményét mind a program oldaláról, mind pedig a cég szerkezetének az átrendezésével.
Az első dolog, amit leszögezett, hogy a teljesítmény (performance) nem egyenlő a méretezhetőséggel (scalability). A teljesítmény arról szól, hogy milyen hatékonyan működik a rendszer, míg a méretezhetőségnél az a lényeg, hogy mekkora tud lenni ez a rendszer.
Bobby Johnson szerint amikor a teljesítményt elemezzük, akkor jó, ha programbeli hibaként gondolkodunk a témáról.
Ez azt jelenti, hogy fontos tudni, hogy miért történik és mi az oka, azonban tesztekkel ezek könnyen elkerülhetőek, illetve ha mégis van valami probléma, akkor könnyebb megtalálni őket. Igazából az elmondása szerint a Facebooknál jobban működtek ezek a tesztek a hibák megtalálásában, mint az általános tesztek, amiket tényleg hibák megtalálására írtak.
A tesztelés mellett fontos, hogy mérjük is a rendszerünk teljesítményét és mindig legyen viszonyítási alapunk. A mérés során se mindegy, hogy mit tekintünk eredménynek: például, ha az átlagát vesszük a mért időknek, akkor a szélsőséges esetek nagyban befolyásolhatják a végeredményt, ezért jobb, ha az eredmények eloszlását elemezzük. Emellett nyilván fontos az, hogy ne egy fix időt vegyünk figyelembe, hanem a változást az egy héttel ezelőtti időhöz képest, vagy a két héttel ezelőtti időhöz képest, mivel a kód úgyis változni fog, így elengedhetetlen, hogy változzon a várható idő is.
A megfelelő mérés része az is, hogy jól meghatározzuk miből áll a teszt: itt általában a minél egyszerűbb, annál jobb elv érvényesül. Ez azért fontos, mert ebben az esetben könnyebben tud azonosulni a problémával az, akinek meg kell oldania azt, illetve valószínűleg ez a javítás több mindent fog érinteni általánosságban. Egy web alkalmazás esetében például egy nagyon egyszerű és nagyon hatékony mérce, hogy mennyi idő alatt tölt be az oldal, ami általában leköröz mindenféle kifinomult mérést.
Sok elterjedt módszer van arra, hogy hogyan gyorsítsuk a rendszerünket, azonban ezek elég bonyolultak és nehéz jól megépíteni őket. Az egyik ilyen módszer a 'prefetching', amikor előtöltjük a dolgokat, amiket a programunk nagy valószínűséggel használni fog. Bobby Johnson tapasztalata szerint ezek legtöbbször végeredményben csak lelassítják a rendszert és inkább ártanak, mint használnak. Elmondása szerint a leghatékonyabb, ha minél kevesebb kódot kell futtatnia a rendszernek és minél kevesebb dolgot kell csinálnia. Hogy őt idézzem: "The fastest database query is the one that you don't have to run".
Hol keressük a kevésbé hatékony részeket? Kezdjük a legegyszerűbb dolgokkal, mivel a komplikáltakkal általában sok időt töltünk és már meglehetősen optimalizálva van. Például: évekkel ezelőtt, amikor a Facebooknál mérték az oldal teljesítményét, kiderült, hogy az oldal betöltésének kb. 30%-át (!!!) az tette ki, hogy kiírják, hogy melyik ismerősödnek közeledik a születésnapja. Nagyon egyszerű funkció, de soha senki nem foglalkozott azzal, hogy mekkora hatása van az oldal töltési idejére vagy hogy hogyan lehetne ezt optimalizálni.
Ezek után áttértünk arra, hogy egy cégként vagy szervezetként hogyan közelítsük meg a programunk teljesítményének javítását. A legfontosabb ebből a szempontból, hogy minden csapatban nevezzünk ki egy embert, akinek ez a feladata, de emellett mindenki tekintse ezt saját felelősségének is. Amennyiben megfelelő célokat tűzünk ki, akkor könnyebb őket elérni és mindenki motiváltabb lesz, hogy hozzájáruljon ezeknek az eléréséhez.
A legmegfelelőbb ember, akit minden csapatból kinevezhetünk, az a 'product' srác (azaz a termékkel foglalkozó ember), aki a legtöbbet tud a kódbázisról. Ő tudni fogja, hogy mit is várnak igazán teljesítmény szempontjából az adott részlegen, illetve, hogy hogyan is kéne működnie ennek a funkciónak. Nyilván nem az az elvárás, hogy a kisujjából kirázza, hogy hogyan csökkentse mondjuk 75%-al valaminek a futási idejét, hanem hogy együtt dolgozzon egy ebben a témában jártas emberrel és végül javítsa a rendszer teljesítményét.
Végül egy kis érdekességként szó esett arról, hogy általában akik a különböző rendszerek teljesítményének javításával foglalkoznak, azokat jobban vonzza a 'back-end' (vagyis a háttérben zajló dolgok), ezért ezek a folyamatok általában sokkal jobban vannak ott optimalizálva, mint a 'front-end'-nél (vagyis az előtérben, a felhasználónál futó dolgok). Ebből kifolyólag, ha javítani szeretnénk mondjuk a web alkalmazásunkat, akkor kezdjük a 'front-end'-nél, mert az valószínűleg jobban elhanyagolt és könnyebben javíthatunk rajta viszonylag sokat.
