Csak a tesztemen keresztül!

Szakmai gondolatok informatikai rendszerek teszteléséről.

Gazda

Friss topikok

  • Akron: @Verhás Péter: Az ügyfeled a cég (vezérigazgatóval, Józsi nénivel) A cég ellenőrzi le és veszi át ... (2018.01.31. 14:09) Miért UAT
  • Verhás Péter: @ hrgy: Egy kicsit felhúztam magam, de sebaj. A lényegi állításokban igazad van, ám a személyekre... (2011.10.09. 00:25) A tesztelés nem mindenható
  • crix: Ez a hozzáállás. Sajnos most is. Aztán csodálkoztak itt a népek, amikor bevállaltam a hétvégi munk... (2011.10.05. 16:56) Újra fizetni kell
  • crix: és milyen specifikáció mentén ment át az ügyfél? elég blind? (2011.10.05. 13:41) Ügyfélteszt
  • fqqdk: fitnesse, concordion, és cucumber integráció lesz? (2011.03.05. 13:42) Automatizált tesztelés és üzleti tesztelés

Társblogok

Jónak tűnik, vagy jó?

2009.06.22. 07:48 | Verhás Péter | 28 komment

Nem mindegy. Mármint az, hogy a címben feltett kérdésre mi a válasz. Mert lehet valami jó, ha annak tűnik, de nem biztos, hogy az. Ahogyan ha valami rossznak tűnik, attól még... Szóval ami rossznak tűnik, az rossz is. És ezek miatt nem az a kihívás a tesztelésben, hogy megtaláljuk a hibákat, hanem az, hogy ha nincsenek hibák, akkor ebben biztosak lehessünk. (Szerencsére ez ritkán fordul elő.)

Amiről ez eszembe jutott, az egy pár évvel ezelőtti tesztelés volt. Egy webes alkalmazás terheléses tesztjében segédkeztünk egy fejlesztő csapatnak. Funkcionálisan teszteltük a szoftvert, tényleg jó válaszokat adott (egy idő után), már csak azt kellett kimérni, hogy nagy terheléseknél is elég gyorsan adja-e a válaszokat.

A teszt tesztelése során előbb kis terhelésnél néztük a válaszidőket, tulajdonképpen összeraktuk, kvázi teszteltük a tesztelést, hogy jól mérünk-e; utána pedig a névleges terhelésnél néztük meg, hogy megfelelően gyorsan válaszol-e a rendszer.

És láttuk, hogy ez jó.

Azaz majdnem. Ami zavart egy kicsit (az ilyenekre mindig nagyon oda kell figyelni), hogy ugyan 1TPS és 2 TPS terhelés esetén még elég kicsi volt az átlagos válaszidő, de már 10TPS környékén nagyobb, és igaz az is, hogy még 100TPS-nél is kisebb volt a válaszidő, mint a maximális megengedett de, de, de …

100TPS-nél kisebb volt a válaszidő, mint 10TPS-nél.

És szerintem ez nem volt jó.
 

De persze kit érdekel délután négykor, hogy hogyan hullámzik a válaszidő ha elegendően jó? A fejlesztő látja, hogy jó szoftvert ír, jön a válasz takkra, ahogy kell, foglalkozzunk a behűtött sörrel.

Momentán, engem érdekelt. Négy óra után ott maradtam (volt kulcsom) és nekiálltam mérni. Apró lépésekben, és a következő ábrát kaptam (csak a jelleg érdekes):

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Az átlag válaszidő természetesen nulláról indul (nincs kérdés, arra baromi gyorsan van válasz), majd növekszik, és meglepő módon egy idő után elkezd csökkenni, és a maximális megkövetelt terhelés esetén már elég kicsi, és csak sokára kezd el nőni, és száll el a végtelenbe.

Hogy mi is történt itt, azt egy hét múlva elárulom. Azok között, akik addig a helyes választ kitalálják és megkommentezik egy eredeti AltaVista Revolution könyvet sorsolok ki (igazi relikvia), amit majd az Angol utcai irodánkban adunk át.

A bejegyzés trackback címe:

https://csakatesztemenkeresztul.blog.hu/api/trackback/id/tr471200235

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.

fanta (törölt) 2009.06.22. 14:29:59

csak kötekedek :)

a válaszidő nem 0-ról indul, mert ha nincs kérés nincs válasz

fanta (törölt) 2009.06.22. 14:38:00

ja a tippem, hogy valaki valahol cache-el

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2009.06.22. 15:43:57

@fanta: Tippnek nem rossz.

De ha cache lett volna, akkor egy idő után a közepes terhelésnél is kisebb átlagos válaszidőnek kellett volna jönnie.

fanta (törölt) 2009.06.22. 17:39:43

@Verhás Péter: ok, viszont szerintem ez így túl általános, ahhoz, hogy egy jó válasz legyen, de lehet, h tévedek

fanta (törölt) 2009.06.22. 17:50:14

lehet többször is tippelni? :)

verhasi · http://verhas.com 2009.06.22. 18:02:41

@fanta: Igen lehet többször is tippelni. Jól tippelni viszont csak egyszer. Bár az igazi relikviából van még egy példány :)

fanta (törölt) 2009.06.22. 19:02:12

@verhasi: :>

A cache-elés mellett, gyorsítást buffer-eléssel lehet elérni, és annak tipikusan nagyobb "forgalom" mellett "érződik" a hatása.

lotht 2009.06.22. 21:49:23

És milyen volt a teszt minta? Abban előálló ismétlődés és cache együttesen különösen alkalmas lehet ilyen jelleggörbe előállítására...

PeterBogyo · http://ujbuda.kutyaiskola.eu 2009.06.23. 10:07:56

Ha java volt akkor ez a híres (hirhedt) memóriaszivárgás probléma lehet. Az abból áll ,hogy a java egy id után rosszul kezeli a garabecollectort és elfogyasztja a memóriát. Emiatt az alkalmazás egy idő után lelassul, majd pedig exponenciálisan emelkedni kezd a válaszidő,
Nyertem-e?
ha nem akkor van még tippem:)

PeterBogyo · http://ujbuda.kutyaiskola.eu 2009.06.23. 10:10:11

eszembe jutott, hogy nem volt esetleg nézve h mi az üzenet ami visszajön a kérdésre. Akkor pedig leheto lyan ,hogy sima hibaüzetet jött válaszként, mint a villám.. Aztán vhol betelt vmi és akkor már nem volt képes feldolgozni a kéréseket...

PeterBogyo · http://ujbuda.kutyaiskola.eu 2009.06.23. 10:11:13

vagy csak egyszerű 404 jött, ha már webes cuccról van szó

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2009.06.23. 10:44:08

@lotht: A teszt minta teljesen random volt, nem volt benne ismétlődés. De ha volt is, nem az okozta a gondot.

PeterBogyo · http://ujbuda.kutyaiskola.eu 2009.06.23. 13:02:40

esetleg vhol eltimeoutolt a szerver, nem válaszolt az alkalmazás. Vagy azt hitte DoS és vmi védekező mechanizmus rebootolta a gépet. Eközben az alkalmazás cache-elte az adatokat és egyben zúdította rá az újraéledő szerverre?
hmm?

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2009.06.23. 14:06:04

Egyre elvadultabb ötletek jönnek, ami nem baj. De azért már megvan a jó válasz, esetleg lehet még finomítani rajta.

A működés egyébként stacionér volt, tehát időben nem változott. Az átlagos válaszidő csak a terheléstől függött.

PeterBogyo · http://ujbuda.kutyaiskola.eu 2009.06.23. 14:25:03

@Verhás Péter: és mikor hírdeted ki h mi az? csak jövő héten?

fanta (törölt) 2009.06.23. 21:31:07

akkor a bufferelést továbbragoznám.
ugye arról szól a téma, hogy van egy "feldolgozó" (F), ami kap kéréseket/adategységeket (K/A) és ahelyett, hogy egyesével dolgozná fel őket, csinál egy buffer-t/queue-t (B/Q), és ebbe várja a hozzá érkező K/A-kat. vegyük pl. h F elég összetett és sokkal gyorsabban dolgoz fel több K/A-t, mint egyet-egyet (vagy feldolgozási sebessége eltérő mint a környezete által hozzá passzolt adatok). Ezért F azt csinálja, hogy figyeli a B/Q-t, amibe ha kerül K/A, azt nem kezdi el azonnal feldolgozni, hanem vár egy kicsit (T), hátha jön még K/A. Aztán T idő után, vagy ha B/Q tele van feldolgoz...

(A válaszidő görbe ívét T és B/Q mérete határozza meg)

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2009.06.24. 08:07:34

@fanta: Ez nem magyarázza meg az átlag válaszidő növekvő terhelés melletti csökkenését. Attól ugyanis, hogy batch-ekben dolgoz fel egy program adatokat, mert puffereli a bemenetén, csak az történik, hogy egy adott terhelés mellett hol lassabban, hol gyorsabban válaszol.

Az átlag válaszidő azonban, adott terhelésnél egy átlag, és ha növelem a terhelést, akkor csak a batch/queue/puffer miatt nem fog a növekvő terhelés mellett csökkenni az átlag válaszidő.

PeterBogyo · http://ujbuda.kutyaiskola.eu 2009.06.24. 09:46:55

a memóriaszivárgós elméletemet megmagyaráztam, azon nincs mit finomítani. A másik tippemet kicsit jobban kifejtem, hátha az a nyertes.

Tehát a grafikonon látszik ,hogy az első csúcspontig az alkalmazás megfelelően és szabályszerűen működött tehát minnél több TPS annál nagyobb válaszidő. A tetőpontot történt a törés. Én azt feltételezem, hogy innentől nem a megszokott válasz (ami mondjuk 100kb) érkezett, hanem csak egy 404 vagy hibaüzenet, ami egyrészt nincs 1kb sem, másrészt mivel nincs figyelve, hogy helyes e a visszajött válasz (kérdés h van e figyelve), ezért aztán nem hibát dob, hanem elfogadja mint jó eredményt. Ez egy ideig szépen működik. Jön a kérés és rögtön jön is rá a hibaüzenet.. Minden szép és jó :) Közben egyre nő a TPS egészen addig a pontig amikor már a szerver nem képes feldolgozni az adatokat (ezért jó lenne látni közben a proci és a memória kihasználtságot, meg persze egy kb/sec adat sem ártana) Feltételezem, hogy a proci már 100%on prög.. Ekkor kezd queueben várni a tranzakció, ami mivel közben nő a TPS ezért egyre jobban megtelik még végül vmi overflow történik és innentől nem ad választ a szerver. A válaszidő timeoutra fut és a grafikon exponenciálisan nő.

Hát ez a másik feltevésem kifejtése.. bár gondolom közel sem kellően szakszerő:) de én vmi ilyesmire tippelnék, ha nem memóriaszivárgás...

fqqdk 2009.06.24. 17:44:31

Nekem Nuunius 404-es verziója szimpatikus, úgy tudnám elképzelni, hogy valami jó kis thread safety issue játszott be. Alacsony terhelésnél egy szál szolgálta ki a kéréseket, aztán ahogy nőtt a terhelés, aktiválódott egy újabb szál, aztán egyszercsak jól összevesztek és mondjuk korrumpáltak együttes erővel valami fontos cuccot, amitől a továbbiakban gondolkodás nélkül lehetett hibaoldalakat visszaadni, és ettől a válaszidő szépen visszacsúszott.

tvk · http://kodzaj.blog.hu 2009.06.25. 00:06:58

Pedig nekem is hasonló tippem lenne mint fantának: van valahol pl. a bemeneten egy fix méretű puffer, aminek a tartalma "lustán" ér el a feldolgozóhoz. Vagy akkor ha lejár egy timeout vagy akkor ha teli van. (Hiányzó close vagy flush.)

A görbe első része adódhat abból, hogy timeout során közvetlenül egymás után mennek be a pufferből a kérések a feldolgozónak és ez megakasztja.

A második része azért lehet csökkenő, mert a beérkező kérések kilökik a pufferből a régebbieket a feldolgozó számára. Ezen a helyen a görbe és a válaszidő a kérések közti időt tükrözi. (1/tps).

A harmadik részben már a pufferolvasás és a feldolgozás fizikai korlátai érvényesülnek: exponenciális.

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2009.06.25. 14:50:20

Érdemes volt ezt a bejegyzést megírni, mert szuper kommenteket írtok! Sokat tanulok belőle én is, és remélem mindenki aki olvassa a kommenteket.

Egy kicsit furcsán érzem magam, hogy nem mondhatom meg (hétfőig), hogy mi a megoldás, mert így egy kicsit úgy tűnik (magamnak legalábbis), hogy én a nagyokos bezzeg milyen okos vagyok mert tudom a megoldást. Pedig csak arról van szó, hogy én tettem fel a kérdést...

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2009.06.25. 14:59:23

@tvk: A görbe stacionér állapotot jelenít meg. (ezt már írtam)

Ez azt jelenti, hogy a teszt elindul pl. 10tps terheléssel, és ezt tartja. Kijön egy átlag. Utána a rendszer újraindul, és a tesztet megint elindítjuk 20tps terheléssel. Megint beáll egy átlagos válaszidő. Majd a rendszert újraindítjuk, és terhelünk 30tps-sel és így tovább.

A kapott átlagos válaszidők vannak a függőleges tengelyen, a vízszintes tengelyen a terhelés.

Egy teszt alatt időben nem változik a terhelés.

Ezért a pufferes megközelítés, mint megoldás nem jó. Elvileg sem.

Ugyanakkor a szokásos, egyszerűbb terheléses tesztek esetében, ahol elkezdjük kis terheléssel és "tekerjük a potit" növelve a terhelést, és nézzük, hogy mi történik: lehet ilyen jelenség. De pont ezért nem így tesztelünk.

Ha már belementem (erről is inkább külön postot kellene írni): terheléses tesztet definiált (ebbe beleértve a randomizáltat is) időbeli eloszlású terheléssel kell csinálni, hogy jó eséllyel reprodukálható legyen, ha valami funkcionális hibát találunk közben.

fanta (törölt) 2009.06.25. 16:13:12

mindenesetre tudnék olyan puffer-stratégiát, amitől ilyen lesz a terhelés görbe - még ha lehet nehéz lenne is megideologizálni :)

tvk · http://kodzaj.blog.hu 2009.06.25. 19:48:38

@Verhás Péter: Én is abból indultam ki hogy állandó a terhelés és szerintem ilyenkor is kialakulhatnak efféle görbék blokkolós I/O csatornák használatánál. De mindegy, mert a görbe első részéről magamat sem sikerül meggyőznöm, hogy miért van az a hirtelen nagy ugrás.

Viszont van még két tippem, mert nem hagy nyugodni a kérdés:

Azzal is összefüggésbe hozható a dolog, hogy a ritkásabban érkező kérések objektumainak több ideje van "megöregedni" a memóriában, így nehezebb őket kisöpörni. A Java GC is ilyen objektum generációkkal operál -a fiatal objektumokat máshogy kezeli- de okozhatja valami magasabb szintű cache mechanizmus is. Igazából a GC-t csak akkor kezdeném méregetni ha már semmi más ötletem nincs, mert ebben az opcióban nem nagyon hiszek.

Vagy egyszerűen van egy housekeeper szál, ami túl sok időszeletet kap ha ritkák a bejövő kérések és túl sok ideig tart neki elvégezni a dolgát, terhel. Sűrűbb kéréseknél viszont már nem kap szót. Ez például pont lehet GC vagy cache karbantartó szál, vagy valami hülyeség.

PeterBogyo · http://ujbuda.kutyaiskola.eu 2009.06.30. 09:14:18

őőő izé, mikor tudjuk meg mi a helyes megoldás? Csak mert szét fúrja az oldalamat a kiváncsiság

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2009.06.30. 16:10:30

@Nuunius: Hamarost. Hét elején egy kicsit több munka esett be, mint vártam...

De az nem baj.
süti beállítások módosítása