HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • sagabona: szia... elég régen született ez a bejegyzés, én csak most akadtam rá véletlenül. Érdekes dolgokat írsz, részben egyetértek az általad gondoltakkal, azonban pár dologban messze más a véleményem - ez ... (2018.10.19. 11:14) Gondolatfoszlányok a pályaválasztásról
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

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).

Címkék: hiba performancia

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr965211451

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

imre 2010.12.08. 15:41:30

megint izgalmas téma ... kapcsolódva a másik oldalról én a megelőző tevékenységekben jobban bízom, és szerintem nem igaz, hogy ne lehetne a performancia problémákat tervezés és tesztelés szintjén megoldani, feltárni. > A performancia hiba ... hiszen > nem funkcionális követelmény, > ezért nem része az igény specifikációnak. szakirodalom hogy ellentmondjak : http://my.safaribooksonline.com/book/software-engineering-and-development/patterns/9780735623989/requirement-pattern-catalog/ch09 ---- A topikban lefektetett kérdéseket - tesztelési és követelmény szinten lefedi a: Performance, Load, Stress, and Scalability Testing

imre 2010.12.08. 16:18:26

A kérdés amit még feltennék ( akár mint új blogtémák ..) : - az elkészült szoftver átvételekor ki lehet-e szűrni az esetleges performancia/skálázódási problémákat? - Agilis megközelítés milyen megoldásokat ad ennek a problémának a kezelésére ... ------------- Azért néha írhatnál valami jó hírről - sikersztory-ról is .. :-)

Ismeretlen_102125 2010.12.08. 16:28:19

Valóban jó témefelvetés, majd megírom :) Az agilis megközelítés meg inkább ront mint javít a helyzeten - erről inkább ne itt hanem holnap este beszéljünk.

m 2010.12.09. 02:18:17

azért van olyan is, hogy a performancia-probléma egyszerűen abból eredt, hogy a szoftvert eredetileg csak ideiglenesre / alacsony konkurens felhasználószámra, stb. terveztették ("csak most év végén oldja meg a problémát" ill. "ezt a [speciáis területet felölelő] rendszert egy tucatnál soha nem fogják többen egyidejűleg használni"). Aztán az egyszeri (tűzoltó) megoldást utólag a megrendelő általános megoldássá tenné, vagy annyira jól működik egy tucat emberrel, hogy rögtön kipublikálná még egy tucat csoportnak... és akkor hirtelen az egész megroskad, szembetűnővé válnak a "tervezési hibák"... holott valójában a szoftver jó (arra, amire eredetileg készült), csak már nem arra, vagy nem úgy akarják használni. Mert azért architektúra, patternek és best practice-ek ide vagy oda, a projekt költségvetése, határideje és az eredeti scope általában behatárolja a lehetőségeket...

Ismeretlen_174680 2010.12.09. 08:43:34

A specifikációnak nem része az, hogy hányan fogják használni? Nálunk igen, ez is. Szerződésben le van írva, hogy ennek a szoftvernek ilyen hw szerveren, ilyen db szerveren, ilyen desktop op. rendszeren, ilyen hálózati mellett stb. + ennyi konkurens felhasználóval ezt, azt és amazt max. t1,t2, t3 idő alatt kell elvégeznie, generálnia, előkeresnie, megjelenítenie, lefuttatnia. Erre aztán lehet terheléses tesztet végezni. Így ha a felhasználó kért egy 8 fős kisbuszt, utána nem reklamálhat, hogy nem fér bele egy 20 fős osztály a kiránduláshoz.