Mi a teendő, ha a végzetesen meglassult a program, emiatt nem használható és a user-ek fellázadtak?

Mi a teendő, ha a végzetesen meglassult a program, emiatt nem használható és a user-ek fellázadtak?

Performancia problémák gyakran azért fordulnak elő, mert az alapok nincsenek rendben, azaz vagy hibás az architektúra, vagy elmulasztották a szükséges kapacitás tervezést.

A performancia hiba alattomos ellenség, hiszen nem funkcionális követelmény, ezért nem része az igény specifikációnak. Másrészt pedig a performancia apránként is el tud romlani. Harmadrészt pedig mivel a tesztelést sok esetben funkcionálisan végzik, kimarad a performancia teszt, és a tesztlaborban tökéletesen muzsikáló rendszer éles környezetben 10 felhasználó után összeomlik.

Hogyan lehet ezeket az alapvető hibákat kivédeni:
- Új funkció fejlesztésénél fel kell tenni a kérdést, hogy hány felhasználó fogja használni, és a funkció milyen extra terhelést jelent az adatbázisra, interfészekre nézve
- Szoftver továbbfejlesztésnél újra fel kell tenni ezt a kérdést, azaz a jelenlegi terheléshez képest az új release milyen extra terheket fog róni a környezetre
- Az architektúrális tervezésbe be kell vonni az Üzemeltetést, illetve az Enterprise Architect-et, és kikérni a véleményüket (bármennyire is sérti ez egyes Architekt-ek önbecsülését)
- Szabvány technológiákat használni (lásd skálázhatóság és stabilitás)
- „Minden nap új release” helyett jól megtervezett release-ek legyenek!

A kapacitás tervezés nagyjából a következő dolgokat jelenti:
- Tisztességgel felmérni és írásban rögzíteni a teljesítmény elvárásokat
- Ezek alapján legjobb tudásunk szerint becsülni a szükséges kapacitást (szakértők bevonásával)
- Folyamatosan monitorozni az éles környezetben
- Új felhasználók bevonását új release-ként kezelni, akkor is ha nincs kód változás a rendszerben
- Archiválási folyamat kidolgozása – lehetőség szerint automatikus!

Ha valaki tisztességgel elvégezte a fentieket, nos az sem jelent garanciát a megfelelő teljesítményre.

(Rövid kitérő a nem-informatikus olvasók kedvéért: ha a szoftver nem bír 100 felhasználónál többet kezelni, az nem feltétlenül azért van, mert a programozó rossz kódot írt. Nyilván nincs a szoftvernek olyan paramétere, hogy „hány felhasználót tud kezelni”. Ha lenne, 100-ról felemelnénk 100000-re – de nincs ilyen.
A 100 a környezet sajátosságaiból adódik: az adatok, függvényhívások stb egy összetett környezeten mennek keresztül – mint egy csövön – ahol bármelyik elem összeszűkülése esetén meglassul a folyamat – és a szoftver. Ez elég ha egyetlen függvényre előfordul, az egész szoftvert képes bedönteni.)

Szóval mi a teendő, ha a gondos tervezés, a konzultáció és az odafigyelés ellenére performancia problémák vannak? Nagyjából a következőket lehet csinálni:

- Különböző eszközökkel (pl. Profiler) megnézni, hogy a futási idő nagyobb részét mi teszi ki. A kritikus részeket nagyító alá lehet venni és javítani.
- Kilistázni a sok CPU-t/lemezterületet felhasználó processzeket és megnézni mit csinálnak.
- Coding standards kidolgozása, és utána ennek ellenőrzése a megírt kódon.
- Annak végiggondolása, hogy üzleti folyamat szempontból tényleg szükség van-e mindegyik adatra, mindegyik függvényhívásra, mindegyik report-ra?
- Ellenőrizni, hogy az interfészt/output-ot tényleg használja-e valaki.
- Archiválás

Mivel a performancia problémákat legtöbb esetben a megszokás okozza („az a programrész BIZTOSAN jó úgy, ahogy van”), ezért nagyon hatékony külső tanácsadó bevonása. Itt a hangsúly nem a tanácsadón hanem a külsőn van – egy kívülről jövő friss ember még mindent megkérdőjelez, és pillanatok alatt képes megtalálni a szemünkbe lógó gerendát.

Nagyon hatásos lehet tehát egy tanácsadó ideiglenes bevonása, majd az útmutatások alapján javítani a kódot.

A hosszú távú megoldás viszont minden esetben a fenntartható kód és a hosszú távú informatikai tervezés (IT Roadmap).