Akkor beszélgessünk róla. [ Ugye tegezhetlek ? Kösz. ]

• GL: Hogyan írjunk lassú alkalmazást ? (ezt itt én mondom)
• Te: Milyen alkalmazást ? (ezt itt Te mondod)
• GL: Szinte bármilyet.
• Te: Tervezzük meg alaposan !
• GL: Jó ötletnek tűnik.

Szedjük össze a szükséges inputokat, a böngészőből, adatbázisokból, hívjuk meg a szükséges web szolgáltatásokat, végezzük el a számításokat, állítsuk össze a kumulált adatokat, írjuk vissza az egészet az adatbázisba és a felhasználói felületre – esetleg az eredménnyel is hívjunk meg egy másik rendszert, majd zárjuk le a tranzakciót. Eközben naplózzunk minden egyes általunk fontosnak vélt lépést.

Ha mindez elkészült, kezdhetjük a következő kéréssel.

Tudom ! Senki nem tervez ilyen programot – esetleg egy volt kolléga távoli ismerőse, aki csak vi-vel tud szöveget szerkeszteni - de azért tegyük fel a példa kedvéért, hogy mégis.

A program (valószínűleg) hibátlanul működik – amíg használatba nem veszik, mert akkor kiderül , hogy  lassú.

Csináljunk vele valamit.

Itt jön az „M” (menedzser) opció: Vegyünk nagyobb gépet – ezt ignoráljuk.

Nézzük meg miért lassú. Mit látunk? A CPU nincs kihasználva, az I/O aktivitás alacsony. Akkor mi történt?

Szép szekvenciális programunk ott futkározik a (majdnem) legkorszerűbb gépünknek hol egyik, hol másik magján. Van belőle vagy 4-8-16, mert annyi kell egy szerverbe. Minél több van annál kisebb átlagos terhelést látunk.

• Te: Szuper ! Ezt tanultuk az iskolában ! Többszálasítunk !
• GL: Lehet ? Nem lehet ? Ha igen, hogyan ?

Sok kérdés jön még itt, mire megleljük (ha megleljük) a helyes választ.

• A feldolgozás algoritmusa megengedi, hogy egyszerre több szálon dolgozzuk fel ?
• Nincsenek ezek egymásra hatással ?
• Esetleg a feldolgozás sorrendje is fontos ?

[ Gyógypedagógiás példa egy backend alkalmazás esetén: az egymást követő feladatok: létrehozni egy új ügyfelet, majd beállítani a hitelkereteit. Ne próbáljuk meg ezt a két dolgot párhuzamosítani ! ]

Tegyük fel, hogy a feldolgozandó kérések mégis csak függetlenek, és valami webes frontendről származnak.

• Te: Akkor többszálasítsunk ! Minden kérés külön száll.
• GL: Jó ötlet(nek tűnik). Amíg 2-5-10 párhuzamos kérésünk van. És ha 100, vagy 10000 ?

Tudom, vannak thread poolok és Te ilyet nem csinálsz– de annak a volt kollégának a távoli ismerőse is tudott róla, és mégis …

Aztán van még egy gond – vagy kettő.

Az egyik az, hogy a két hasonló művelet jó eséllyel az adatbázis azonos tábláit fogja piszkálni és az adatbázis kezelő szépen sorba rakja a kéréseket. (Ugye fel sem merül olyan eszköz használata, ami ezt nem teszi, vagy a tranzakció kezelés ignorálása.)

A másik gond az, hogy több párhuzamos kérés esetén a válaszidő – jó esetben és egy ideig - alig fog nőni, de az egyes kérések válaszideje nem csökken – márpedig drága felhasználónknak előjön a homok allergiája, ha homokórát lát.

„M” (menedzser) opció: Vegyünk nagyobb gépet – egyelőre még ignoráljuk.

Nincs más hátra, gondolkodni kell – és mérni. Rájövünk, hogy az idő jelentős része megy el a logolással, az üzenetek megszerkesztésével és lemezre írásával.

• Te: Csökkentsük le a logolások mennyiségét.
• GL: Rossz ötlet.

Nyilván azért tettük bele, mert így követhető mi is történik a programunkban, ami annyira komplex, hogy már mi sem értjük pontosan, jövő hónapra pedig biztosan elfelejtjük. Amikor meg szüksége lesz valakinek rá, már régen egy másik cégnél dolgozunk. Opció törölve.

• Te: Akkor kapcsoljuk ki az éles rendszerben – ott úgyse fejlesztünk.
• GL: Rossz ötlet.

Soha nincs nagyobb szükség a részletes logra, mint akkor, amikor az éles rendszeren találunk olyan hibát, ami csak a téli napfordulót követő harmadik munkaszüneti napon jön elő.

[ Jelen sorok írója töltötte már a szilveszter délelőttjét bankban, mert azokban az években, amikor szilveszter keddre esik az utalások a következő év szilveszterére lettek időzítve. ]

Ezt az opciót is töröljük.

• Te: Akkor most hogyan tovább ?

Logolni kell, sokat logolni jó, várni a feldolgozással, hogy ez megtörténjen nem jó. Ne várjuk meg.
Még szerencse, hogy az iskolában tanítottak olyat, hogy szinkron és aszinkron kommunikáció. A szerencsésebbek még emlékeznek rá. A logolandó adatokat gyűjtsük össze, és küldjük el egy üzenetben egy jó vágású naplózó szálnak, majd az elszöszmötöl vele. Szerverünkben meg úgyis hemzsegnek az unatkozó processzor magok.

• Te: Heuréka. Akkor most gyorsabbak vagyunk.
• GL: De nem eléggé.
• Te: Akkor most jöhet az „M” (menedzser) opció: Vegyünk nagyobb gépet?
• GL: Talán még ne.

Ha ez az üzenetküldés ilyen jó ötletnek tűnik a naplózásnál, nem lehetne ezt máshol is használni ? Hát (háttal nem kezdünk mondatot – csak indokolt esetben), amikor a feldolgozás eredményével meghívunk egy web szolgáltatást, meg kell azt nekünk várni ? Nem.(*) Akkor használjunk ott is üzenetküldést !

(*) – Ennek ugye az a feltétele, hogy olyan üzenetküldő infrastruktúrát használjunk, ami garantálja az üzenetek célba érkezését.

Lehet, hogy a felhasználói válaszban sincs szükség a teljes feldolgozás eredményére ? Nosza, hasítsuk azt is ketté !

• Te: Akkor most hol tartunk ?
• GL: A feldolgozásunkat nem párhuzamosítottuk, hanem sorosítottuk (lásd még: pipe line).

Miért jó ez ? Az egyes részek dedikált feladatot látnak el, mindegyik megkaphatja a maga erőforrásait – ide értve a CPU magokat is. Ezek nagy valószínűséggel nem fognak ütközni. A válaszidő lerövidült, a CPU erőforrásait hatékonyan ki tudjuk használni.

• Te: És ha még mindig nem elég gyors ?
• GL: Még mindig nem tartunk az (M) opciónál.

Most, hogy a feldolgozást fázisokra osztottuk, már meg tudjuk nézni, hogy mi nem elég gyors. Na, azt a fázist kell párhuzamosítani – feltéve, ha megfelel a fenti feltételeknek.

• Te: És ha még mindig nem elég gyors ?
• GL: Most alkalmazzuk az (M*) opciót
• Te: Mi az a (M*) opció ? 
• GL: Vagy inkább az (M) opció módosított változatát.

Most már tudjuk, hogy nem egyszerűen „nagyobb” gépet kell venni, de már pontosan ismerjük az alkalmazásunk erőforrás igényeit, és tudjuk, hogy memóriában, CPU-ban vagy I/O kapacitásban alakult ki a szűk keresztmetszet.

Én pontosan tudom, hogy mindenki (Te is) pontosan így jár el, de a volt kollégám távoli ismerőse számára ezt biztos újdonság, és megkértem a nagyszakállút, hogy csempéssze ma a csizmájába.

Gács Lajos

EAI Architect