A lassúság okai

A felhasználók számára egy alkalmazás soha nem lehet elég gyors. Azt azonban már korántsem könnyű kideríteni, hogy egy szoftver mitől lassú, és hogyan lehetne növelni a teljesítményét.

Egyetlen cégvezető előtt sem kell bizonygatni, hogy az üzletmenet gyakorlatilag minden aspektusa a vállalati alkalmazásoktól függ. De ahogy egyre erősebb lett ez a függés, úgy nőttek a benne rejlő kockázatok is. Egy modern nagyvállalat ma már akár több száz – készen kapható és egyedileg fejlesztett – alkalmazást is használhat, így komoly veszélyek leselkednek az üzletmenetre az olajozottan működő szoftvergépezet kirakata mögött.

Passzivitás
Súlyos pénzeket költenek el a vállalatok az alkalmazások bevezetésére, ám utána már sokkal kevesebb figyelmet fordítanak azok folyamatos karbantartására – egészen addig, amíg be nem következik egy végzetes szoftverhiba, ami az egész alkalmazás leállásához vezet. Mi több, egy Gartner-felmérés szerint az informatikai rendszerek kiesésének leggyakoribb oka a szoftverhiba, megelőzve még a biztonsági veszélyeket is (lásd a grafikont). A következmények pedig pusztítóak: egy másik felmérés szerint a szoftverhibából eredő nem tervezett leállások a nagyvállalatoknak évente a bevétel 3,6 százalékára rúgó kárt okoznak.

Ennek ellenére az alkalmazások teljesítményének kezelése többnyire paszszív és reaktív módon történik. A hangsúly többnyire csak a karbantartáson és a funkcióbővítésen van, a proaktív teljesítménykezelés és -optimalizálás rendszerint a háttérbe szorul. Természetesen az alkalmazások nagy száma és széles választéka sem segít a teljesítmény optimalizálásában.

A nagyobb alkalmazások rendszerint már a kiszolgálók és a kommunikációs berendezések elkülönülő rétegei által alkotott többszintű architektúrát igényelnek. Egy ilyen környezetben a hálózatban működő különféle alkalmazások közötti kapcsolatok, együttműködések kiszámíthatatlanok. Ráadásul a teljesítményüket nagymértékben csökkenthetik azok az ügyfélalkalmazások, amelyeket a felhasználók engedély nélkül telepítenek gépükre (videolejátszók, hálózati játékok), és amelyek irdatlan mennyiségű hálózati erőforrást képesek lekötni.

Kézben tartott teljesítmény
Felismerve, hogy az alkalmazások gyenge teljesítménye egyre inkább növekvő probléma, az előretekintő vállalatok olyan alkalmazásfigyelő megoldásokat kezdenek alkalmazni, amelyek a hálózati teljesítmény kezelésének kifinomultságát és mélyreható elemzési képességeit hozzák el a szoftverek világába. Az ilyen, alkalmazásteljesítmény- kezelő rendszernek nevezett megoldás lehetővé teszi a hálózatért és az alkalmazásokért felelős rendszergazdáknak, hogy közösen azonosítsák és oldják meg az alkalmazások gyenge teljesítményének okait – mégpedig a hálózat oldaláról közelítve, például figyelve az egyes alkalmazások által igénybe vett sávszélesség változásait, a forgalom alakulását és a válaszidőket.

Az alkalmazások teljesítményére vonatkozó mérőszámok részletes képet adnak a rendszerekről, és számos módon használhatók:

  • megérthető belőle, hogy a vállalat technológiai infrastruktúráját hogyan hasznosítják az üzleti célok elérése érdekében;
  • azonosíthatók és megkereshetők az engedély nélküli alkalmazások;
  • a hálózat vagy az alkalmazások bővítése érdekében tervezhető a kapacitás;
  • fokozható a biztonság azáltal, hogy azonosítják a kártékony, rosszindulatú programok, kódok által generált hálózati tevékenységet.

Információs csatorna
Az alkalmazások teljesítményének felügyelete jelenleg még leginkább a reaktív hibaelhárításra korlátozódik: minél gyorsabban megtalálni a hiba forrását, ha egy alkalmazásról kiderül, hogy a szokásosnál lassabban teljesít – így a minimálisra lehet csökkenteni az üzletre gyakorolt hatását. A következő lépéseket követve kialakítható egy olyan információs csatorna, amelybe betáplálhatók a részletes információk, azokat elemezve pontosabb képet lehet kapni az alkalmazások teljesítményét befolyásoló tényezőkről.

Első lépés: az alapértékek meghatározása. Mind a hálózat, mind a legfontosabb alkalmazások teljesítményének alapértékeit meg kell határozni, hogy kiderüljön: milyen teljesítmény várható el normál körülmények között. Ha gond van az alkalmazásokkal, ezek az alapértékek lehetőséget teremtenek az azonnali összehasonlításra.

Második lépés: alkalmazásfolyamatelemzés. A hálózatmenedzserek jól tudják, hogy a csomagszintű adatok gyakran életbevágóan fontosak számos probléma megoldásában. Hasonló módszer használható az alkalmazásteljesítményt mérő megoldásoknál is, amelyek a folyamat (flow) szintjén elemzik az alkalmazást, és összesített statisztikákat közölnek a teljesítmény legfontosabb tényezőiről: alkalmazás, ügyfél, szerver, virtuális helyi hálózat, idő. Azzal, hogy az alapadatokat felhasználható információvá alakítják, növelhető a hatékonyság, és a minimálisra csökkenthető a válaszidő.

Harmadik lépés: a probléma kategorizálása és izolálása. Egy jó rendszer segít a rendszergazdáknak eldönteni a teljesítményprobléma pontos okát és természetét. Ezek között lehet:

  • alkalmazáskód (teljesen mindegy, hogy egy alkalmazás milyen természetű, ha a kódját rosszul írták meg, soha nem fog hatékonyan működni);

  • hálózati infrastruktúra (korábban az alkalmazások gyenge teljesítménye miatt rendszerint a szűkös sávszélességet okolták, aztán amikor a sávszélesség olcsóbb lett, és növelték a hálózati kapacitást, sokszor kiderült, hogy a probléma gyökere egészen máshol van);

  • protokollok (előfordul, hogy a gyengén „muzsikáló” alkalmazás mögött egy nem kellőképpen hatékony hálózati protokoll a ludas, a megfelelő felügyeleti eszközök segítenek az ilyen problémák felderítésében, és támpontot nyújthatnak a protokollok jobb behangolásához – például, hogy mekkora legyen az adatcsomagok mérete);

  • hardver, operációs rendszer (az erőtlen szerver, az elavult operációs rendszer szintén oka lehet az alkalmazások rossz teljesítményének).

Negyedik lépés: tapasztalati tények gyűjtése. A legfejlettebb teljesítménykezelő megoldások lehetővé teszik, hogy a felhasználó grafikus formában is megjelenítse és vizsgálja az alkalmazás teljesítményének különféle aspektusait, például a sávszélesség-igényt vagy egy lekérdezési- válaszadási ciklus idejét.

Hálózat és alkalmazás
Minthogy az alkalmazások többnyire nem „légüres” térben működnek, nagyon fontos lehet annak eldöntése, hogy a hálózat teljesítménye hogyan és mennyire fogja befolyásolni az alkalmazás teljesítményét. Az alapértékek meghatározása tesztkörnyezetben történhet: összegyűjthetők a megfelelő adatok a válaszidőkről és az egyéb jellemzőkről. A hálózati alkalmazások jellegzetességei azt is meghatározzák, hogy miképpen kell a teljesítményüket mérni. (Ebből a szempontból három alkalmazástípus van, ahogy az a táblázatban olvasható.)

Az elvégzett mérések és a begyűjtött információk kiértékelése alapján elkülöníthetők a teljesítménybeli gondok. Sokszor kiderülhet, hogy a látszólag az alkalmazásban jelentkező gond hálózati okokra vezethető vissza.

A késleltetésre érzékeny alkalmazások – mint mondjuk az IP alapú hangátvitel – például megfelelő mennyiségű erőforrást igényelnek ahhoz, hogy jól működjenek. A teljesítménymenedzsment- eszközök elegendő alapadatot kínálnak ahhoz, hogy a rendszergazdák részletesen megismerjék a hálózati forgalom természetét, és annak megfelelően tudják konfigurálni a hálózatot és az eszközöket.

Egy másik ok lehet a nem kellőképpen hatékony protokollkonfiguráció: a csomagok méretének vagy más változóknak a variálásával csökkenteni lehet a hálózati terhelést. Sokszor csak az segít, ha a terhelés csökkentésének érdekében újabb alkalmazásszervereket állítanak használatba. Ha túl sokan és túl sok helyről próbálnak használni egy alkalmazásszervert, úgy tűnhet, hogy a program nem elég gyors – miközben egyszerűen a hálózat van túlterhelve a szervernél. Ilyenkor az lehet a megoldás, hogy regionális kiszolgálókat állítanak üzembe.

Alkalmazás és hálózat
Végül az alkalmazások teljesítménykezelésének egy további módja, amikor a hálózatról összegyűjtött adatokkal igyekszünk felmérni, hogy az újonnan üzembe állított szoftver milyen hatással lesz magának a hálózatnak a teljesítményére.

Ilyenkor azt a négy tényezőt szokták a leginkább vizsgálni, amelyek a legközvetlenebb módon érintik a hálózati alkalmazások teljesítményét:

Sávszélesség-igény. Ha az egyes alkalmazásfeladatok által felemésztett sávszélesség meghaladja a jelenleg rendelkezésre álló mennyiséget, akkor mindenképpen helyénvaló a bővítés. A teljesítménykezelő eszközök rendszerint 5 vagy 15 perces időközönként végzik el a mérést; ennyi idő alatt természetesen számos alkalmazásfeladat végrehajtódik. Ugyanakkor alkalmas annak kimutatására, hogy mennyire sávszélesség-érzékeny egy alkalmazás.

Alkalmazásfordulók. Egy alkalmazásforduló egy lekérdezés és a rá adott válasz párjából áll. Minél több fordulót igényel egy alkalmazás, annál lassabban fog működni, különösen, ha ebben még olyan felesleges fordulók is vannak, amelyek tovább terhelik a hálózatot. Ha sikerül csökkenteni a fordulók számát, azzal komolyan lehet növelni az alkalmazás teljesítményét.

Alkalmazásérzékenység. A sávszélességre és a fordulókra vonatkozó információkból kiderülhet, hogy egy alkalmazás inkább a sávszélességre vagy a késleltetésre érzékenyebb-e. Az előbbi esetben nagy mennyiségű adat utazik a szerver és az ügyfélgép között, és az elérhető sávszélesség közvetlen hatással van a válaszidőre. A látenciára érzékeny alkalmazások számára jó mérőszám lehet az egy feladat elvégzéséhez szükséges fordulók száma.

Összeállította: Schopp Attila

További tartalmak

Legolvasottabb tartalmak

Strategy

Valós idejű adózás

Human

Az egészség hálózatai

Technology

Egy év, amely átírta az emberiség és a mesterséges intelligencia viszonyát

Strategy

Exportcikk lehet a DÁP-ból

ITBUSINESS heti hírlevél feliratkozás

.
Scroll to Top