Teljesítmény tesztelés

A teljesítmény (performance testing vagy röviden PET) során azt vizsgáljuk, hogy az alkalmazásunk – a mi esetünkben szinte mindig a magento webáruház – mennyire terhelhető. A vizsgálat végén a kapott adatok alapján kimutatásokat készítünk és tanácsokat adunk arra nézve, hogy az alkalmazásunk mely pilléreit (szoftver, hardver, egyéb) kell megerősítenünk abban, hogy még jobban terhelhető, optimálisabb teljesítményű legyen.

A Magento webáruház rendszer egyik sarkalatos pontja a teljesítmény és ezzel a betöltési sebesség. Mivel egy alapvetően robusztus és komplex rendszerről van szó, mely telepítése után már az eladáshoz és vásárláshoz is kidolgozott, összetett folyamatokkal rendelkezik, ezért sejthető, hogy a hagyományos tárhelyek nem eléggé specifikáltak a megfelelő támogatottságához. A folyamatok teljes mértékben testreszabhatóak, ehhez elegendő a konfigurációs felület használata, így jelentősen megnövelve a feldolgozási időket, a memória használatot és ezzel a szerver válasz idejét, elérhetőségét is – akár még a szerver stabilitását vagy összeomlását is kockáztathatjuk.

A Tsung egy megfelelő eszköz arra, hogy ezeket a folyamatokat teljesítmény tesztekkel terheljük és megtaláljuk azokat a töréspontokat, melyeket a webáruház publikálása után el szeretnénk kerülni. Ilyen speciális folyamatok például a háttérben futó újraindexelés, a kosár használata, a regisztráció és a különböző mélységű kategóriákban a különböző darabszámú termékek megjelenítése is. A szerver szempontjából kritikus lehet az állományok olvasási/írási sebessége (munkamenetek, képek, szkriptek, stb.), a memória és háttértárak korlátai, a CPU feldolgozási sebessége vagy éppenséggel a hálózati adatforgalom mennyisége.

Mi is az a teljesítmény tesztelés?

Az ISTBQ (International Software Testing and Qualification Board) szerint  teljesítmény tesztelés nem más, mint a “Tesztelési folyamat, mellyel a szoftvertermék teljesítményét lehet meghatározni.”.

A Wikipédia szerint: Tesztelési folyamat, ami meghatározza, hogy milyen gyors a rendszer egy bizonyos szempontból, adott terhelés alatt. Ezen kívül validálhat és verifikálhat más minőségi tényezőket is, mint skálázhatóságot, megbízhatóságot vagy forrás kihasználtságot.

Tehát egy olyan nem funkcionális tesztelési folyamat, ami az alkalmazás (szoftver, azaz magento webáruház) teljesítményével foglalkozik és a fejlesztés teljes szakaszában használható a problémák felfedésére és megelőzésére.

Szerintem a Wikipédia megállapítása áll a legközelebb a meghatározáshoz, azonban pontos definíciót adni, mint sok más esetben, itt sem lehet.

Miért van szükséged teljesítmény tesztelésre?

Az internet térhódításával egyre többen élnek az online vásárlás lehetőségével, így egyre többen érik el a webáruházakat is. Manapság már az emberek többsége ahelyett, hogy a boltba menne és kipróbálná a terméket az eladótól segítséget kérve, már szinte igazi szakértőként keresgél, összehasonlít és vizsgál a világ minden webáruházának termékeiből, hogy számára a legmegfelelőbbet találja meg. Egy ünnep vagy nagy akció (mint például a Karácsony vagy a Fekete Péntek) közeledtével pedig a boltok helyett a web világában rohanják meg a vásárlók áruházunkat.

Ezeket a megnövekedett terheléseket vagy a folyamatos nagy mennyiségű forgalmat áruházunknak ki kell szolgálnia, ezért is szükséges a teljesítmény tesztelése.

A webáruházat több komponens alkotja, van szoftveres, hardveres és hálózati keresztmetszet része is, melyek további szegmensekre bonthatóak egészen a használt keretrendszer, a szerver processzorának teljesítménye vagy a letöltött oldal kódjának adat mennyiségéig. Ha ezekre nem figyelünk oda, akkor egy-egy kiugró terhelés esetén a webáruházunk lelassulhat, elérhetetlenné válhat vagy a legrosszabb esetben teljesen össze is omolhat.

A PET fajtái

Az alábbi felsorolásban ismerjük meg a releváns teljesítmény tesztelés fajtáit, a teljesség igénye nélkül, kiemelve a webáruházakon alkalmazott legfontosabb teszteléseket. Részletesebb a wikipédia szoftver tesztelés leírását tudom ajánlani, ahol olvashatunk további információkat még ezekről.

1. Terheléses tesztelés (Load testing): A legegyszerűbb teszt, mivel itt azt verifikáljuk, hogy az alkalmazás hogyan viselkedik normális vagy magasabb terhelés alatt, változik a viselkedése közben?
   1. Tűrőképesség teszt (Endurance testing): Hosszabb ideig tartó, folyamatos terhelés mellett vizsgálja a rendszer működését, így az egy-két órás tesztek alatt rejtve maradó problémákat az akár több napos teszt segíthet a felszínre hozni.
2. Stressz tesztelés (Stress testing): Ideális esetben arra használjuk, hogy megismerjük a rendszer felső határait, a töréspontokat. Ez a teszt típus kész meghatározni a rendszer robosztusságát extrém terhelés közben és segíti az adminisztrátorokat, hogy meghatározzák a rendszer ideális működési tartományát és maximumát.
   1. Kapacitás teszt (Capacity testing): A Stressz tesztelés folyamán megállapítjuk, hogy mennyi felhasználót/lekérdezést/műveletet tud egyszerre végrehajtani hibamentesen a rendszer.
3. Kitartás tesztelés (Soak testing): A normális működés szimulálva a kitartás teszt, egy olyan működés ami képes meghatározni, hogy a folyamatos használati terhelését mennyire bírja a rendszer. A teszt alatt folyamatosan figyelni kell a memóriát és ezzel felderíthetőek a memória szivárgási problémák.
4. Tüske tesztelés (Spike testing): Hirtelen megugrott terhelést adunk a rendszernek, majd ezt ugyanilyen hirtelen lecsökkentjük. Ez a hirtelen változás “tüskeként” jelenik meg a rendszer terhelésének grafikonjában, innen kapta a teszt a nevét.
5. Konfigurációs tesztelés (Configuration testing): Felmerülhet a kérdés, hogy ez a teszt mit keres a teljesítmény tesztek között. Mivel ez a teszt azt vizsgálja, hogy a konfigurációs beállítások megváltoztatásával milyen hatással van a rendszer részeire vagy egészére, elsősorban a teljesítményére, ezért a besorolása pontos.
6. Izolációs tesztelés (Isolation testing): A teljesítmény tesztelésnek nem egy egyedi típusáról van szó, inkább egy ismétlődő tesztelésről, ami fényt derít egy rendszer problémára. A tesztek gyakran külön környezetekbe izoláltak és a teszt eredményeként csak a hibás környezetet kapjuk eredményül.

A tesztelés lépései

• Tesztkörnyezet meghatározása (létrehozása, kialakítása)
• Elfogadási kritérium(ok) meghatározása
• Teszt(ek) megtervezése (tesztelési forgatókönyv megírása)
• Tesztkörnyezet konfigurálása (adatfeltöltés, paraméterek beállítása)
• Tesztek implementálása
• Tesztek futtatás
• Eredmények kiértékelése, riportok készítése, újrafuttatás

Tsung (IDX-Tsunami 1.6.0)

A Tsung egy megosztott terheléses teszt eszköz. Protokoll függő és jelenleg a következő protokollal kommunikáló szervereken futtatható:

• HTTP
• WebDAV
• SOAP
• PostgreSQL
• MySQL
• LDAP
• Jabber/XMPP

A Tsung fő erőssége, hogy képes szimulálni egyetlen gépről nagy mennyiségű felhasználót. Ha több gépen (klaszter) használjuk, akkor pedig igazán lenyűgöző teljesítményt tud produkálni, mindezt könnyen konfigurálhatjuk és fenntarthatjuk.

Jellemzők

• Magas teljesítmény
• Elosztott működés
• Több protokoll támogatás
• SSL támogatás
• Különböző IP címek kiosztása azonos gépről
• Operációs rendszer monitorozása a tesztelés alatt
• XML konfigurációs rendszer
• Dinamikus forgatókönyvek (tranzakciók)
• Kevert viselkedés a felhasználóknak (munkamenetek)
• Sztohasztikus feldolgozás (thinktime)

Mi az az Erlang és miért fontos?

A Tsung-ot Erlang nyelven fejlesztették és ez az ami olyan erőssé teszi, mivel az Erlang egy konkurens-orinetált programozási nyelv. Az Erlang OTP (Open Transaction Platform) képezi a Tsung alapját, ami így jellemzően a következő jellemzőkkel ruházza fel:

• Teljesítmény
• Skálázhatóság
• Hibatűrő képesség

Protokollok és teljesítmény

A Tsung nagy teljesítményre képes, ha a megfelelő hátteret biztosítjuk a számára. Számokban ez az alábbiakat jelenti:

• Jabber/XMPP protokoll:
  • 90,000 szimulált JABBER felhasználó egy 4-es Tsung klaszteren.
  • 10,000 szimulált felhasználó: Tsung 3 számítógépből (800MHz-es CPU) álló klaszteren.
• HTTP és HTTPS protokoll:
  • 12,000 szimulált felhasználó: Tsung 4 számítógépből álló klaszteren (2003) 3000 lekérés/másodperccel.
  • 10,000,000 szimulált felhasználó: Tsung 75 számítógépből álló klaszteren több, mint 1,000,000 lekérés/másodperccel.

Tsung konfigurációs lehetőségek

Az alábbi lista a teljesség igénye nélkül készült, részletekért keresd fel a Tsung konfigurációs XML dokumentációját:

• Felhasználók felső határának korlátja (maxusers)
• Dinamikusan és statikusan létrehozható felhasználók
• Szakaszok maximális futási idejének meghatározása
• Felhasználók “gondolkozási idejének” beállítása, véletlenszerűség, hibernálás
• Kapcsolat időtúllépésének megadása
• Ismételt próbálkozások száma, ha a kapcsolat nem épült fel
• HTTP, LDAP authentikáció lehetősége
• MySQL lekérdezések futtatása
• Variálható munkamenet típusok
• Külső (CSV) állományok betöltése és feldolgozása
• Dinamikus változók használata (JSONPath, Regexp, XPath, PostgreSQL, dinmaikus változók)
• Iterációk megvalósítása (for, repeat, if, foreach)

Tapasztalatok és a valóság

A teljesítmény tesztek nem terjednek ki minden folyamatra vagy minden szerver elemre, azonban, ha a folyamat jól meghatározott és várható a terhelés, akkor pontos képet tud adni. Egy általános magento környezeti teszttel például néhány perc alatt megállapítottuk, hogy a munkamenetek (session) állományokba írása és olvasása, valamint emellett a nem megfelelően kezelt naplózás és a képek gyorsítótárazásának hiánya olyan terhelést okozott, mely egyszerű beavatkozással megszüntethető lett.

Egy alap (minimális modulokkal bővített és nem egyedi megoldásokat használó) magento áruház 50-100 konkurens felhasználó esetén már a legjobb szerveren is akadozni, lassulni fog, míg a megfelelő gyorstárazással, elosztott szerverekkel ez az érték akár 3-5000-re is növelhető. Ha csupán a böngészést nézzük, akkor pedig ennek az értéknek akár a 3-4-szerese is elérhető, amire a reális esély elég alacsony.

Jellemzően azonban elmondható, hogy a memória alapú munkamenet kezelés (Redis) és a frontend oldali gyorsítótárazás az egyik kulcsfontosságú az oldalaknál – természetesen abban az esetbe, ha a kód nem okoz teljesítmény problémát, ami tovább gyűrűzik a gyorstárakra is -, majd csak ezután következik a hatalmas méretű adatbázis és a nem megfelelően felépített backend oldali kódbázis okozta terhelés. Mindegyikre remek megoldásokkal rendelkezünk.

Összefoglalás

A teljesítmény tesztelés kiemelten fontos az e-commerce megoldásoknál, főleg a magento webáruházaknál, hiszen a felhasználók gyorsan, akadály- és hibamentesen akarnak eljutni a vásárlás végéig és megkapni termékeiket. Főleg ünnepnapok, akciók és jól célzott marketing reklámok után számítanunk kell komoly terhelésre, így azoknak akik szeretnék a vásárlóikat megtartani és nem arról híressé/hírhedtté válni, hogy a webáruházuk elérhetetlen erősen javasolt a teljesítmény tesztelés.

A Tsung egy megfelelő eszköz arra, hogy teljesítmény teszteket valósítsunk meg, akár az egész áruházra, vagy az egyes folyamatokra (adatbázis terhelés, fizetés, stb.), mindezt a legismertebb és leginkább használt protokollok támogatása mellett. Könnyű konfigurálása miatt ideális eszköz arra, hogy rövid tanulással is komoly, minden tekintetben profi teszteket futtassunk. Az automatikus jelentés készítésével pedig mindezt emberek számára is érthető formába öntsük, grafikonokkal színesítve.