Tesztelési jegyzőkönyv

Tesztelési jegyzőkönyv verzió: 1.0

Verziókövetés Verzió: 1.0.

Készítette: Török Tamás

Leírás: Dátum: A Neptun -> NIIF LDAP adatbázisok 2004. június 14. közötti szinkronizációs komponens (synctool) tesztelésének jegyzőkönyve

-1-

Tartalomjegyzék 1. A tesztelési jegyzőkönyv célja......................................................................................................3 2. A megoldás tesztelése.................................................................................................................3 2.1 Tesztkörnyezet............... ............................ ............................ .............. 3 2.1.1 Neptun Oracle DB...........................................................................3 2.1.2 NIIF LDAP címtár............................................................................3 2.1.3 Synctool.......................................................................................4 1. A tesztelés...................................................................................................................................6 3.1 A tesztelés módszertana........................................................................6 3.2 Tesztelési esetek..................................................................................8 3.2.1Teljes adatbázis feltöltés - „INSERT”...................................................8 3.2.2Teljes adatbázis feltöltés - „INITIALIZATION”.....................................10 3.2.3 1000 rekord - „INSERT..................................................................12 3.2.3 1000 rekord - „INITIALIZATION”.....................................................14 3.2.4 5000 rekord - „INSERT”.................... ............. ............ ............. .......16 3.2.5 5000 rekord - „INITIALIZATION”.....................................................18 3.2.6 10000 rekord - „INSERT”...............................................................20 3.2.7 10000 rekord - „INITIALIZATION”...................................................22 3.2.8 Teljes adatbázis feltöltés módosított kóddal - „INSERT”........... ............ 24 3.2.9 Teljes adatbázis update módosított kóddal - „INITIALIZATION”............26 4.A tesztek értékelése....................................................................................................................28 5.Javaslatok...................................................................................................................................29 6.A megoldás értékelés, kitekintés................................................. ................................................ 31

-2-

1. A tesztelési jegyzőkönyv célja A tesztelési jegyzőkönyv célja a synctool komponens működésének rövid áttekintésén túl a tényleges működési környezetben végzett teszt futtatások eredményeinek ismertetése, az eredmények magyarázata illetve a javaslatok összefoglalása a még hatékonyabb működés érdekében. Szorosan nem tartozik a teszt procedúrához, azonban röviden össze kívánjuk foglalni azokat az előnyöket, amelyekkel a jelen komponens rendelkezik, megkönnyítve ezzel konkrét összehasonlítások készítését.

2. A megoldás tesztelése 2.1 Tesztkörnyezet A megoldás tesztelését az NIIF szakembereivel korábban egyeztetett módon a gödöllői Szent István Egyetemen (SzIE) végezzük el. A kialakított megoldás gyakorlatilag három, egymástól független komponenst tartalmaz.

2.1.1 Neptun Oracle DB A Neptun rendszer hallgató adatbázisa egy Oracle adatbázis, amely jelen esetben gyakorlatilag „fekete dobozként” értelmezhető komponens. A Neptun adatbázisa felé egyetlen ponton, az ottani SQLNet listeneren keresztül kapcsolódunk (TCP 1521-es port) és egyetlen táblát (LDAP_LOG) vagyunk képesek elérni. Az LDAP_LOG táblában alapértelmezetten keresési műveleteket hajtunk végre (SQL Select), azonban jogosultsággal rendelkezünk rekordok törlésére is. A rendszer működése szempontjából elengedhetetlenül szükséges: • Kapcsolódás az Oracle adatbázishoz SQLNet-en keresztül • Keresési és törlési jogosultság az LDAP_LOG táblában

2.1.2 NIIF LDAP címtár

-3-

Az LDAP címtár jelen pilot esetében a SunONE Directory Server 5.2 verziója, azonban bármely olyan LDAP alapú címtár használható, amely szabványos LDAP (v2 vagy v3) protokollon keresztül elérhető. Szükséges, hogy a használni kívánt címtár sémája ki legyen egészítve az NIIF által használ speciális objectClass-okkal és attributumokkal. Az LDAP címtárban olvasási és módosítási műveleteket hajtunk végre, ezért elengedhetetlen, hogy mind a módosításokra, mind az olvasásokra jogosultsággal rendelkezzen az a „felhasználó”, akinek a jogosultságával elérjük a címtárat. (Itt természetesen azon LDAP ágra vonatkozó jogosultságokról van szó, amely LDAP ágban a felhasználói adatokat tárolja a címtár). A tesztelések során „Directory Manager” jogosultsággal értük el a címtárat, azonban az éles környezetben mindenképpen oda kell figyelni a jogosultságokra (megfelelő ACI-k beállításával). A rendszer működéséhez elengedhetetlenül szükséges feltételek: • LDAP (alapértelmezetten TCP 389) kapcsolat a Directory Server irányába • Directory Server sémájának kiegészítése az NIIF specifikus sémával • Megfelelő jogosultságok (olvasás/módosítás) biztosítása a hallgatói LDAP ágra

2.1.3 Synctool A Synctool komponens valósítja meg a kapcsolatot az Oracle adatbázis és az LDAP címtár között. A kapcsolat a jelen változat esetében gyakorlatilag egyirányú. Nagyon legegyszerűsítve, a szinkronizációs folyamat során a synctool az Oracle adatbázist olvassa, konverziót, transzformációt végez a kiolvasott rekord mezőin és az így előállított objektumot írja az LDAP szerverbe. A folyamat során természetesen elengedhetetlen a címtár olvasása (pl. objektum létezésének ellenőrzése, mail címek egyediségének vizsgálata) illetve az Oracle adatbázis írása (a sikeresen feldolgozott rekord törlése).

A Synctool komponens a jelen megoldás esetén egy perl nyelven megírt alkalmazás, amely feltételezi, hogy az adott számítógépen a perl futtatókörnyezet (5.8.3-as verzió), a perl környezet kiterjesztését jelentő perl modulok és az Oracle kliens -4-

rendelkezésre áll. A fentiek közül minden szükséges komponens ingyenesen hozzáférhető a legelterjedtebb platformokon (Sun Solaris Sparc/x86, Linux, Windows), így azok beszerzése járulékos költséget nem jelent.

-5-

A komponens működése szempontjából elengedhetetlenül szükséges: • perl 5.8.3 futtatókörnyezet • perl modulok telepítése: DBI, DBD::Oracle, Net:LDAP, ConfigReader:Simple, Text::Unaccent • Oracle kliens telepítése • TCP (SQLNet) kapcsolat az Oracle és (LDAP) az LDAP szerver irányába

1. A tesztelés 3.1 A tesztelés módszertana A tesztelés során olyan tesztelési helyzeteket (scenáriókat) kívántunk megvizsgálni, amelyek igen hasonlóak az éles rendszerben majdan használatos környezettel, ugyanakkor alkalmasak a megoldás esetleges gyenge pontjainak a feltárásához. Az eredeti elképzeléseink szerint a tesztelést különböző mennyiségű input adatot feltételezve (különböző mennyiségű adat az Oracle LDAP_LOG táblában) különböző műveletekre végeztük volna el, azonban ezt az elképzelést módosította néhány peremfeltétel illetve felismerés: •

Az Oracle táblába a számunkra rendelkezésre álló eszközökkel (tárolt eljárás) tetszőlegesen csupán teljes „INSERT” rekordokat tudunk felvinni. Ezen „INSERT” rekordok számát ugyan tetszőlegesesen tudjuk módosítani, azonban a rendelkezésre álló eszközökkel nem tudunk tisztán „UPDATE” és „DELETE” rekordokat generálni. -6-

•

•

Az „INSERT” rekord esetében a négy kívánatos művelet („INSERT”, „INITIALIZATION”, „UPDATE”, „DELETE”) közül két műveletet tudunk teljes mértékben megvalósítani („INSERT”, „INITIALIZATION”), azonban mind az „UPDATE”, mind a „DELETE” műveletek visszavezethetőek az „INITIALIZATION” műveletre, hiszen teljesen azonos tevékenységeket kell mindhárom esetben végezni, csupán a „mennyiség” különböző. Az „INITIALIZATION” művelet esetében kell a legnagyobb számosságú módosítást végrehajtani, ezért kijelenthetjük azt, hogy az „UPDATE” és a „DELETE” műveletek legrosszabb esetben sem jelenthetnek nagyobb terhelést, hosszabb végrehajtást mint az „INITIALIZATION” műveletek. Ezen megközelítést alkalmazva a négy művelet valójában redukálható kettőre. A tesztek eredményeinek (és a fejlesztés korábbi fázisában már elvégzett kontrollmérések) összehasonlítása során bizonyos esetekben elég komoly eltérések adódtak. Ennek okát vizsgálva egyértelművé vált, hogy a kód egy jól meghatározott pontjának (erről a későbbiekben részletesen említést teszünk) módosításával illetve az Oracle adatbázishoz történő hozzáfér megváltoztatásával drasztikusan befolyásolható lenne az eredmény. Ezen felismerést követve elvégeztük a tesztek egy részét olyan formában is, amikor az adott kódrészletet kihagyva (és ezzel együtt a lényegi feladatát a synctool komponensnek nem változtatva) mértük az eredményeket.

A tesztelés során a fentiek értelmében két műveletre végeztük el a méréseket („INSERT” és „INITIALIZATION”). A feldolgozott rekordok mennyiségét tekintve méréseket végeztünk a teljes elérhető adatbázisra (23724 rekord), illetve méréseket végeztünk 1000, 5000 és 10000 rekord esetében. A korábban említett „problémás” kódrészlet kihagyása esetén ugyan csak méréseket végeztünk a mindkét művelettel a teljes adatbázisra. A ténylegesen elvégzett mérések mennyisége természetesen jóval magasabb azoknál az eredményeknél, amelyeket jelen jegyzőkönyvben ismertetünk. Az eredmények értékeléséhez miden esetben három mérést végeztünk el, majd az egymáshoz eredményben közelebb eső két mérés adatait dolgoztuk fel. Természetesen ez a megközelítés igazából nem képes kiszűrni a mérési hibákat, azonban a nagyon durva befolyásoló tényezők hatását talán csökkenti. Itt jegyezzük meg azt is, hogy a mérések meglehetősen időigényes folyamatok – itt nem kizárólag a mérésre magára kell gondolni, hanem az elékészítő műveletekre is – ezért az esetenkénti három mérés is jóval tovább tartott, mint azt eredetileg számítottuk.

-7-

3.2 Tesztelési esetek 3.2.1Teljes adatbázis feltöltés - „INSERT” A teszt célja: Egyszeri nagy mennyiségű adatfeltöltés modellezése. A teszt menete: A feltöltés során „üres” LDAP adatbázissal indulunk, ezért minden objektum esetében LDAP szinten „ldapadd” műveletet hajtunk végre. A futtatás során az LDAP adatbázishoz hozzáadandó objektum attribútumai az Oracle rekordból származnak illetve származtathatóak. Az egyetlen „dinamikusan” meghatározásra kerülő attribútum a mailcím, aminek az egyediségét az LDAPban történő kereséssel kell és lehet meghatározni.

-8-

A teszt eredménye: Szükséges idő

átlag

Min.

Max.

(entry/perc)

(entry/perc)

(entry/perc)

Futás 1.

00:43:04

539.2

478

627

Futás 2.

00:42:11

539.18

507

657

A teszt értékelése: A futtatáshoz szükséges időtartam a teszt jelen formájában meghaladja a várakozásunkat, azonban véleményünk szerint belül marad azon a határon, ami – az ilyen jellegű futtatás gyakoriságát figyelembe véve – elfogadható egy intézmény számára.

Teljes "INSERT" 25000

Feldolgozott rekordok

22500 20000 17500 15000 12500 10000 7500 5000 2500 0 0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4

percek

-9-

3.2.2Teljes adatbázis feltöltés - „INITIALIZATION” A teszt célja: Egyszeri nagy mennyiségű adat módosítása. A művelet során a teljes hallgatói adatbázis „újra” generálódik az Oracle adatbázisban, azonban az LDAP címtárban ez már módosításként jelentkezik, mivel az objektumok meglévő LDAP objektumokra vonatkoznak. A teszt annak az esetnek a szimulációja, amikor valamilyen okból a teljes hallgatói adatbázist újra kell generálni az LDAP-ban. A teszt menete: A teszt során „feltöltött” LDAP adatbázissal indulunk, ezért minden objektum esetében LDAP szinten „ldapmodify” műveletet hajtunk végre. A futtatás során az LDAP adatbázishoz hozzáadandó objektum attribútumai az Oracle rekordból származnak illetve származtathatóak. Amennyiben az LDAP objektum (hallgató az LDAP adatbázisban) már rendelkezik mail attribútummal, akkor a mail attribútum értékét a folyamat érintetlenül hagyja.

- 10 -


átlag

Min.

Max.

(entry/perc)

(entry/perc)

(entry/perc)

Futás 1.

01:57:50

199.37

71

317

Futás 2.

02:11:14

179.73

84

289

A teszt értékelése: Az összes teszteset közül ez a futtatás igényelte a legtöbb időt, azonban a közel 24000 rekord feldolgozása még így is 2 óra körül mozgott. Feltételezhetően az ilyen típusú futtatásra igen ritkán fog sor kerülni, amennyiben mégis ezt a műveletet kell futtatni, akkor javasoljuk az éjszakai vagy hétvégi futtatást.

Teljes "INITIALIZATION" 25000


22500 20000 17500 15000 12500 10000 7500 5000 2500 0 0246811111222223333344444555556666677777888889999911111111111111111 02468024680246802468024680246802468024680246800000111112222233 02468024680246802

percek

- 11 -

3.2.3 1000 rekord - „INSERT A teszt célja: Viszonylag kevés hallgatói adat egyszeri adatbetöltésének szimulációja. A teszt során azt az állapot kívánjuk modellezni, amikor viszonylag kisszámú hallgató kerül újonnan felvételre a rendszerbe. A teszt menete: A feltöltés során „üres” LDAP adatbázissal indulunk, ezért minden objektum esetében LDAP szinten „ldapadd” műveletet hajtunk végre. A futtatás során az LDAP adatbázishoz hozzáadandó objektum attribútumai az Oracle rekordból származnak illetve származtathatóak. Az egyetlen „dinamikusan” meghatározásra kerülő attribútum a mailcím, aminek az egyediségét az LDAPban történő kereséssel kell és lehet meghatározni.

- 12 -


átlag

Min.

Max.

(entry/10 másodperc)



Futás 1.

00:01:22

100

95

121

Futás 2.

00:01:36

111.22

125

124

A teszt értékelése: A teszt során az 1000 hallgatóra vonatkozó LDAP bejegyzések kevesebb mint 2 perc alatt jöttek létre, ami véleményem szerint egy éles működés esetén teljes mértékben elfogadható.

1000 rekord "INSERT" 1100


1000 900 800 700 600 500 400 300 200 100 0 0

1

2

3

4

5

6

másodpercek (x10)

- 13 -

7

8

9

10

3.2.3 1000 rekord - „INITIALIZATION” A teszt célja: A teszt célja viszonylag csekély mennyiségű hallgatói adat módosításának szimulálása. Hasonló helyzet lehet tanulmányi időszakban a normális működés során fellépő adatmódosítások lekövetése. A teszt menete: A teszt során „feltöltött” LDAP adatbázissal indulunk, ezért minden objektum esetében LDAP szinten „ldapmodify” műveletet hajtunk végre. A futtatás során az LDAP adatbázishoz hozzáadandó objektum attribútumai az Oracle rekordból származnak illetve származtathatóak. Amennyiben az LDAP objektum (hallgató az LDAP adatbázisban) már rendelkezik mail attribútummal, akkor a mail attribútum értékét a folyamat érintetlenül hagyja.

- 14 -


átlag

Min.

Max.




Futás 1.

00:03:38

43.52

23

27

Futás 2.

00:03:58

40

124

53

A teszt értékelése: Az 1000 hallgatóra vonatkozó módosítások minden futtatás esetében kevesebb mint 4 perc alatt „érvényre jutottak” az LDAP adatbázisban. Egy éles rendszer esetében ez a válaszidő teljes mértékben elfogadható.

1000 rekord "INITIALIZATION" 1100


1000 900 800 700 600 500 400 300 200 100 0 0

1

2

3

4

5

6

7

8

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

másodpercek (x10)

- 15 -

3.2.4 5000 rekord - „INSERT” A teszt célja: Egyszeri közepes mennyiségű adatfeltöltés modellezése. A teszt futtatásával a beiratkozási időszak terhelését szimuláljuk a rendszeren. A teszt menete: A feltöltés során „üres” LDAP adatbázissal indulunk, ezért minden objektum esetében LDAP szinten „ldapadd” műveletet hajtunk végre. A futtatás során az LDAP adatbázishoz hozzáadandó objektum attribútumai az Oracle rekordból származnak illetve származtathatóak. Az egyetlen „dinamikusan” meghatározásra kerülő attribútum a mailcím, aminek az egyediségét az LDAPban történő kereséssel kell és lehet meghatározni.

- 16 -


átlag

Min.

Max.




Futás 1.

00:07:14

113.64

110

122

Futás 2.

00:07:17

112.73

106

123

A teszt értékelése: Az 5000 hallgatóra vonatkozó insertek kevesebb mint 10 perc alatt megtörténtek. Ez éles működést feltételezve „szinte azonnali” szikronizálást jelent, valószínűleg a sebesség elfogadható.



4500 4000 3500 3000 2500 2000 1500 1000 500 0 0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

másodpercek (x10)

- 17 -

3.2.5 5000 rekord - „INITIALIZATION” A teszt célja: Egyszeri közepes mennyiségű adatmódosítás modellezése. Ilyen jellegű műveletre valószínűleg a tárgyfelvételi időszakban kerül sor. A teszt menete: A teszt során „feltöltött” LDAP adatbázissal indulunk, ezért minden objektum esetében LDAP szinten „ldapmodify” műveletet hajtunk végre. A futtatás során az LDAP adatbázishoz hozzáadandó objektum attribútumai az Oracle rekordból származnak illetve származtathatóak. Amennyiben az LDAP objektum (hallgató az LDAP adatbázisban) már rendelkezik mail attribútummal, akkor a mail attribútum értékét a folyamat érintetlenül hagyja.

- 18 -


átlag

Min.

Max.

(entry/perc)

(entry/perc)

(entry/perc)

Futás 1.

00:26:49

178.57

84

250

Futás 2.

00:25:35

192.31

95

314

A teszt értékelése: Az 5000 hallgatóra vonatkozó módosítások kevesebb mint fél órát vettek igénybe, azonban ez a futási idő kicsit hosszú ahhoz, hogy semi-online állapotnak lehessen nevezni.

5000 rekor "INITIALIZATION" 5000


4500 4000 3500 3000 2500 2000 1500 1000 500 0 0

1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

percek

- 19 -

3.2.6 10000 rekord - „INSERT” A teszt célja: Egyszeri közepes mennyiségű adatfeltöltés modellezése. A teszt futtatásával a beiratkozási időszak terhelését szimuláljuk a rendszeren, kontrollként használjuk az 5000 rekordot tartalmazó hasonló teszt mellett. A teszt menete: A feltöltés során „üres” LDAP adatbázissal indulunk, ezért minden objektum esetében LDAP szinten „ldapadd” műveletet hajtunk végre. A futtatás során az LDAP adatbázishoz hozzáadandó objektum attribútumai az Oracle rekordból származnak illetve származtathatóak. Az egyetlen „dinamikusan” meghatározásra kerülő attribútum a mailcím, aminek az egyediségét az LDAPban történő kereséssel kell és lehet meghatározni.

- 20 -


átlag

Min.

Max.

(entry/perc)

(entry/perc)

(entry/perc)

Futás 1.

00:15:20

625

632

698

Futás 2.

00:15:34

625.06

605

697

A teszt értékelése: A teszt során arányaiban gyakorlatilag teljesen hasonló eredmények születtek, mint az 5000 rekordot tartalmazó mérés esetében, ezért igazolva látjuk az ott leírtakat.



10000 9000 8000 7000 6000 5000 4000 3000 2000 1000 0 0

1

2

3

4

5

6

7

8

9

percek

- 21 -

10

11

12

13

14

15

16

3.2.7 10000 rekord - „INITIALIZATION” A teszt célja: Egyszeri közepes mennyiségű adatmódosítás modellezése. A teszt futtatásával a beiratkozási időszak terhelését szimuláljuk a rendszeren, kontrollként használjuk az 5000 rekordot tartalmazó hasonló teszt mellett. A teszt menete: A teszt során „feltöltött” LDAP adatbázissal indulunk, ezért minden objektum esetében LDAP szinten „ldapmodify” műveletet hajtunk végre. A futtatás során az LDAP adatbázishoz hozzáadandó objektum attribútumai az Oracle rekordból származnak illetve származtathatóak. Amennyiben az LDAP objektum (hallgató az LDAP adatbázisban) már rendelkezik mail attribútummal, akkor a mail attribútum értékét a folyamat érintetlenül hagyja.

- 22 -


átlag

Min.

Max.

(entry/perc)

(entry/perc)

(entry/perc)

Futás 1.

00:33:25

178.57

5

662

Futás 2.

00:33:40

192.31

160

719

A teszt értékelése: A teszt során arányaiban hasonló eredmények születtek, mint az 5000 rekordot tartalmazó mérés esetében, ezért igazolva látjuk az ott leírtakat. A két mérés közötti „ingadozás” annak tulajdonítható, hogy valamelyik szerver esetében egyéb zavaró terhelés jelentkezhetett (futás 1. esetében 5 entry/perc minimális érték), azonban a teljes mérésre vonatkozóan ez a „zavar” gyakorlatilag semlegesítődött.

10000 rekord "INITIALIZATION" 10000


9000 8000 7000 6000 5000 4000 3000 2000 1000 0 0 1 2 3 4 5 6 7 8 9 10 11 1 1 14 15 1 1 18 19 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 2 3 6 7 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4

percek

- 23 -

3.2.8 Teljes adatbázis feltöltés módosított kóddal „INSERT” A teszt célja: A teszt során a korábban elvégzett teljes feltöltés kontrollját vizsgáljuk abban az esetben, ha a kód általunk kritikusnak tartott részét (Oracle DELETE művelet) „kikapcsoljuk”. A teszt menete: A feltöltés során „üres” LDAP adatbázissal indulunk, ezért minden objektum esetében LDAP szinten „ldapadd” műveletet hajtunk végre. A futtatás során az LDAP adatbázishoz hozzáadandó objektum attribútumai az Oracle rekordból származnak illetve származtathatóak. Az egyetlen „dinamikusan” meghatározásra kerülő attribútum a mailcím, aminek az egyediségét az LDAPban történő kereséssel kell és lehet meghatározni. A teszt során a kód nem hajtja végre az Oracle „DELETE” műveletet, azt egyszerűen „átugorja”, ezért a futás után az LDAP_LOG táblában minden adat megmarad.

- 24 -


átlag

Min.

Max.

(entry/perc)

(entry/perc)

(entry/perc)

Futás 1.

00:18:13

1186.2

930

1637

Futás 2.

00:22:15

1031.48

512

1415

A teszt értékelése: A módosított kóddal rendelkező program nagyságrendileg feleannyi idő alatt végezte el a futást mint az Oracle „DELETE” műveletet is végrehajtó változat, ezért igazolódva látszik az a várakozás, hogy ez a művelet az egész futtatás „legköltségesebb” része.

Teljes "INSERT" módosított kóddal 25000


22500 20000 17500 15000 12500 10000 7500 5000 2500 0 0

1

2

3

4

5

6

7

8

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23

percek

- 25 -

3.2.9 Teljes adatbázis update módosított kóddal „INITIALIZATION” A teszt célja: A teszt során a korábban elvégzett teljes update kontrollját vizsgáljuk abban az esetben, ha a kód általunk kritikusnak tartott részét (Oracle DELETE művelet) „kikapcsoljuk”. A teszt menete: A futtatás során „feltöltött” LDAP adatbázissal indulunk, ezért minden objektum esetében LDAP szinten „ldapmodify” műveletet hajtunk végre. A futtatás során az LDAP adatbázishoz hozzáadandó objektum attribútumai az Oracle rekordból származnak illetve származtathatóak. Amennyiben az LDAP objektum (hallgató az LDAP adatbázisban) már rendelkezik mail attribútummal, akkor a mail attribútum értékét a folyamat érintetlenül hagyja. A teszt során a kód nem hajtja végre az Oracle „DELETE” műveletet, azt egyszerűen „átugorja”, ezért a futás után az LDAP_LOG táblában minden adat megmarad.

- 26 -


átlag

Min.

Max.

(entry/perc)

(entry/perc)

(entry/perc)

Futás 1.

01:35:08

247.13

98

452

Futás 2.

01:27:13

269.59

100

467

A teszt értékelése: A futtatás időigénye itt is kevesebb (kb. 75%-a), mint az Oracle „DELETE” műveletet is tartalmazó kód esetében volt. A jelentős különbség igazolja azt a feltevést, hogy az Oracle „DELETE” művelet jelen formájában igen jelentősen rontja a performanciát.

Teljes "INITIALIZATION" módosított kóddal 25000


22500 20000 17500 15000 12500 10000 7500 5000 2500 0 02 46 8 11 11 1222 22 33 33 3 44 44 455 55 566 66 67 7777 88 88 8 99 99 02 46 8024 68 02 46 8 02 46 802 46 802 46 80 2468 02 46 8 02 46

percek

- 27 -

4.A tesztek értékelése A korábban részleteiben ismertetett tesztek alapján egyértelműen kijelenthető, hogy a megoldás egy életképes alternatívát képes nyújtani a Neptun rendszer Oracle adatbázisában tárolt hallgatói információk és az intézményeknél megtalálható LDAP alapú címtárak közötti szinkronizációra (jelenleg egyirányú szinkronizációról beszélünk). Az eredeti elképzelések szerint a szinkronizáció gyakorlatilag offline módon történne meg, amit a synctool alkalmazás periodikus futtatásával végeznénk el. A mérési adatok megerősítik azt az elképzelést, hogy a periodikus futtatás képes kiszolgálni a megoldással szemben támasztott követelményeket. Kezdetben a napi futtatást javasoltuk, azonban a mérési adatok alapján ennél jóval gyakoribb futtatás is elképzelhető, hiszen még a legnagyobb terhelést jelentő teljes inicializálás időszükséglete 2 órán belül maradt a 23724 rekordot tartalmazó teszt adatbázisra. Az is látszik a tesztekből, hogy a napi rutint jelentő, csekély mennyiségű változást jelentő futtatások (1000 rekord) a „legrosszabb” esetet feltételező teljes update (INITIALIZATION) esetén is 5 percen belül maradtak, ezért „jó ráhagyással” számolva ezen esetekben az akár 10 percenkénti periodikus futás is elképzelhető lenne, amivel egy gyakorlatilag semi-online állapotot is lépesek lennénk elérni. Nem szabad elfeledkezni a futtatások azon változatáról, ahol a kódból kihagytuk az Oracle delete műveletet. Látszik, hogy ebben az esetben a teljesítmény szempontjából jelentős javulás következett be, ezért egyértelműen kijelenthető, hogy ez a kódrészlet az egész megoldás szűk keresztmetszete.

- 28 -

5.Javaslatok 5.1Módosítások a kódban A javaslataink között feltétlenül első helyen szerepel az Orcale adatbázisban történő törlés teljesítményt visszafogó viselkedésének a közömbösítése. A probléma lényege röviden összefoglalva az, hogy az Orcale táblából feldolgozott rekordokat nem törölheti a synctool alkalmazás feltétel nélkül, mivel pl. LDAP kapcsolati hiba esetében ezen rekordokat egy későbbi futtatás során fogja ismételten feldolgozni. Ezen feltétel miatt az Oracle rekordok törlését „egyenként” tudjuk csak megvalósítani, ami igen rossz hatásfokot eredményez. Megoldást jelenthetne, ha azokat a rekordokat, amelyek nem törölhetően az adott futás során, egy átmeneti (pl. LDAP_LOG_TMP) táblába írhatnánk. Ebben az esetben a futtatás során nem törölnénk egyesével a rekordokat, hanem a futtatás végeztével a teljes LDAP_LOG táblát törölnénk (Oracle „DROP” művelet), majd az LDAP_LOG_TMP táblát átmásolnánk az LDAP_LOG táblába. Ebben az esetben „meg lehetne spórolni” a rekordonkénti „költséges” Oracle DELETE műveleteket és – legalábbis nagyobb számú rekord esetén – jelentősen lehetne csökkenteni a program futásához szükséges végrehajtási időt. A fenti módosítások elvégzése technikailag nem okozna nehézséget, azokhoz annyi változtatásra lenne szükség, hogy az Oracle hozzáféréshez használt felhasználó a műveletek elvégzéséhez megfelelő jogosultságokkal rendelkezzen. 5.2Módosítások az Oracle adatbázisban Az adatbázissal szembeni módosítások az előző pontban említett jogosultság változtatáson kívül arra terjednének ki, hogy a lehetőségekhez képest javítani kellene a „DELETE” művelet performanciáját. Nem vagyunk az Oracle adatbázisok szakértői, ezért nem tudjuk megítélni ennek a valódi realitását, azonban feltételezzük, hogy valamilyen szintű Oracle tuningot el lehetne végezni. 5.3Módosítások az LDAP oldalon Az LDAP adatbázisok működését az alapbeállításokhoz képest jelentős módon hozzá lehet „igazítani” a valódi működési környezethez. Igen sok olyan hangolható paraméter van, amelyek (default értékekhez képesti) módosításával jelentős teljesítményjavulást lehet elérni. - 29 -

Ilyen paraméter lehetnek: •

• • •

Adatbázisok elhelyezkedése a filerendszeren. Itt elsősorban a különböző adatbázisok külön fizikai diszkre kerülését értjük, illetve a temporális adatbázisok áthelyezését a fizikai diszkekről a virtuális (memória) diszkekre. Futtatási szálak (threads) számának módosítása tényleges környezet értelmében (pl. processzorok számától függően változik az optimális beállítás) Adatbázis cache-ek méretének változtatása Adatbázis tranzakció loggolás, durabilitás módosítása

A fenti paraméterek LDAP szerverenként más-más eredményt jelenthetnek (a synctool komponens elvileg bármely szabványok LDAP szerverek képes működni), azonban az mindenképpen igaz, hogy a szerver konfigurációt az adott környezethez (használat módja, HW platform, stb.) legoptimálisabban érdemes konfigurálni. A SzIE-n használt szerveren a kezdeti teszteket követően elvégeztük a legszükségesebb LDAP szerver tuning tevékenységeket, így a mért értékek már egy hangolt szerverrel együttműködve adódtak. Az elvégzett LDAP paramétermódosítások: Attribútum megnevezése nsslapd-threadnumber

Default érték

Módosított érték

30

45

nsslapd-maxthreadsperconn

5

10

nsslapd-db-durable-transaction

on

off

nsslapd-db-transaction-logging

on

off

/sunone/directory/slapd-sun-lab/db

/tmp/nsslapd-db

nsslapd-db-home-directory

- 30 -

6.A megoldás értékelés, kitekintés 6.1Metacímtárak Mielőtt a konkrét megoldás értékelését elvégeznénk, érdemes megvizsgálni, hogy az adott problémát, vagyis egy Oracle adatbázisban tárol hallgatói adatbázist milyen módon lehet LDAP címtárral szinkronizálni. A feladat megvalósítására triviálisnak tűnő megoldás lehetne a metacímtár használata. A metacímtárak alapvető feladata éppen az adatkonszolidáció a különböző adatforrások között. A metacímtárak általában „univerzális” termékek, amelyek már alapértelmezetten is tartalmazzák az LDAP és az Oracle kapcsolódáshoz szükséges konnektorokat, interfészeket. Metacímtárakat a piacon több gyártó is kínál, léteznek megoldásai a nagy cégeknek (pl. Sun, Siemens, Microsoft) éppúgy, mint a specializálódott kissebbeknek (pl. Waveset, Criticalpath, stb.) Az előnyök mellett a metacímtárak több hátránnyal is rendelkeznek. Az egyik legfontosabb hátrány talán az ár, mivel egy viszonylag marginális piacra szükséges igen magas fejlesztési költségekkel egy terméket létrehozni (nem beszél a heterogén rendszerekhez történő rendszerekhez való kapcsolódás igen költséges teszteléséről). Ugyancsak hátrány lehet jelen esetben az (ami talán más esetben előny), hogy a metacímtárak megpróbálnak a lehető leguniverzálisabbak lenni, ezért „csupán két rendszer” összekapcsolása esetében meglehetősen sok „overhead”-et jelentenek egy célalkalmazással szemben. Harmadik, de talán legfontosabb hátrányként azt lehet tekinteni, hogy a „dobozos” termék jellegből kifolyólag a metacímtárak elsősorban egy az egyes adatmegfeleltetésre alkalmasak a két rendszer között, az adatok transzformációjára, módosítására, származtatására jóval kevesebb a lehetőség, mint egy egyedileg, erre a speciális feladatra fejlesztett alkalmazásnál. 6.2Synctool alkalmazás A jelen feladatra kifejlesztett synctool alkalmazás egy speciális megoldás, ami kizárólag a Neptun Oracle és NIIF LDAP adatbázisok között képes (jelenleg) egyirányú adatszinkronizációt végezni. Ilyen tekintetben jóval szerényebb képességekkel rendelkezik, mint a valódi metacímtárak, azonban az adott feladatra teljes mértékben megfelel. A megoldás – saját fejlesztésénél fogva – az adatmanipuláció teljes spektrumát képes megvalósítani, az, hogy mely adat milyen forrásból, milyen formában keletkezzen igazából „csak” specifikáció kérdése. - 31 -

A Synctool alkalmazás teljes mértékben ingyenes komponensekből épül fel, ezek a komponensek bárki számára szabadon hozzáférhetőek, használhatóak. A futtatáshoz szükséges komponensek több platformon is rendelkezésre állnak (Solaris Sparc/x86, Linux, Windows), ezért gyakorlatilag minden olyan platformon képes működni, ami a felsőoktatásban előfordulhat. Az Synctool alkalmazást jelen formájában perl nyelven készítettük el. A perl platform igen gyors és rugalmas fejlesztést tesz lehetővé, ugyanakkor megfelelő futási teljesítményt garantál. A perl platform használata ugyanakkor megkövetel olyan komponenseket is (itt elsősorban az Oracle kliensre gondolok), amelyek talán feleslegesen nagy overhead-et jelentenek. Éppen emiatt – és a még rugalmasabb platformfüggetlenség eléréséhez – javasoljuk a megoldás java nyelvre történő portolását abban az esetben, ha a synctool alkalmazás kerül kiválasztásra egy végleges megoldásként.

- 32 -

Tesztelési jegyzőkönyv

Recommend Documents