Tesztelési jegyzőkönyv

Átírás

1 Tesztelési jegyzőkönyv verzió:. Verziókövetés Verzió: Készítette: Leírás: Dátum:.. Török Tamás A Neptun -> NIIF LDAP adatbázisok közötti szinkronizációs komponens (synctool) tesztelésének jegyzőkönyve. június. - -

2 Tartalomjegyzék. A tesztelési jegyzőkönyv célja...3. A megoldás tesztelése...3. Tesztkörnyezet Neptun Oracle DB NIIF LDAP címtár Synctool.... A tesztelés A tesztelés módszertana Tesztelési esetek Teljes adatbázis feltöltés - INSERT Teljes adatbázis feltöltés - INITIALIZATION rekord - INSERT rekord - INITIALIZATION rekord - INSERT rekord - INITIALIZATION rekord - INSERT rekord - INITIALIZATION Teljes adatbázis feltöltés módosított kóddal - INSERT Teljes adatbázis update módosított kóddal - INITIALIZATION....A tesztek értékelése... 5.Javaslatok...9.A megoldás értékelés, kitekintés

3 . 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.. A megoldás tesztelése. 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... 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 5-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.. NIIF LDAP címtár - 3 -

4 Az LDAP címtár jelen pilot esetében a SunONE Directory Server 5. verziója, azonban bármely olyan LDAP alapú címtár használható, amely szabványos LDAP (v 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 39) 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..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..3-as verzió), a perl környezet kiterjesztését jelentő perl modulok és az Oracle kliens - -

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

6 A komponens működése szempontjából elengedhetetlenül szükséges: perl 5..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. A tesztelés 3. 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. - -

7 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 (37 rekord), illetve méréseket végeztünk, 5 és 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

8 3. Tesztelési esetek 3..Teljes 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. - -

9 A teszt eredménye: Szükséges idő átlag Min. Max. Futás. :3: Futás. :: 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. Feldolgozott rekordok Teljes "INSERT" percek - 9 -

10 3..Teljes 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. - -

11 A teszt eredménye: Szükséges idő átlag Min. Max. Futás. :57: Futás. :: 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 rekord feldolgozása még így is ó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" percek Feldolgozott rekordok

12 3..3 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. - -

13 A teszt eredménye: Szükséges idő átlag (entry/ másodperc) Min. (entry/ másodperc) Max. (entry/ másodperc) Futás. :: 95 Futás. ::3. 5 A teszt értékelése: A teszt során az hallgatóra vonatkozó LDAP bejegyzések kevesebb mint perc alatt jöttek létre, ami véleményem szerint egy éles működés esetén teljes mértékben elfogadható. Feldolgozott rekordok rekord "INSERT" másodpercek (x) - 3 -

14 3..3 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. - -

15 A teszt eredménye: Szükséges idő átlag (entry/ másodperc) Min. (entry/ másodperc) Max. (entry/ másodperc) Futás. :3: Futás. :3:5 53 A teszt értékelése: Az hallgatóra vonatkozó módosítások minden futtatás esetében kevesebb mint perc alatt érvényre jutottak az LDAP adatbázisban. Egy éles rendszer esetében ez a válaszidő teljes mértékben elfogadható. Feldolgozott rekordok rekord "INITIALIZATION" másodpercek (x) - 5 -

16 3.. 5 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. - -

17 A teszt eredménye: Szükséges idő átlag (entry/ másodperc) Min. (entry/ másodperc) Max. (entry/ másodperc) Futás. :7: 3. Futás. :7: A teszt értékelése: Az 5 hallgatóra vonatkozó insertek kevesebb mint 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ó. Feldolgozott rekordok rekord "INSERT" másodpercek (x) - 7 -

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

19 A teszt eredménye: Szükséges idő átlag Min. Max. Futás. :: Futás. :5: A teszt értékelése: Az 5 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. 5 5 rekor "INITIALIZATION" 5 Feldolgozott rekordok percek - 9 -

20 3.. 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 5 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. - -

21 A teszt eredménye: Szükséges idő átlag Min. Max. Futás. :5: Futás. :5: A teszt értékelése: A teszt során arányaiban gyakorlatilag teljesen hasonló eredmények születtek, mint az 5 rekordot tartalmazó mérés esetében, ezért igazolva látjuk az ott leírtakat. Feldolgozott rekordok rekord "INSERT" percek - -

22 3..7 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 5 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. - -

23 A teszt eredménye: Szükséges idő átlag Min. Max. Futás. :33: Futás. :33: A teszt értékelése: A teszt során arányaiban hasonló eredmények születtek, mint az 5 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. 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. Feldolgozott rekordok rekord "INITIALIZATION" percek

24 3.. 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. - -

25 A teszt eredménye: Szükséges idő átlag Min. Max. Futás. :: Futás. :: 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. 5 Teljes "INSERT" módosított kóddal 5 Feldolgozott rekordok percek - 5 -

26 3..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. - -

27 A teszt eredménye: Szükséges idő átlag Min. Max. Futás. :35: Futás. :7: 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. 5 5 Teljes "INITIALIZATION" módosított kóddal Feldolgozott rekordok percek - 7 -

28 .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 órán belül maradt a 37 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 ( 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 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. - -

29 5.Javaslatok 5.Mó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.Mó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

30 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 Default érték Módosított érték nsslapd-threadnumber 3 5 nsslapd-maxthreadsperconn 5 nsslapd-db-durable-transaction on off nsslapd-db-transaction-logging on off nsslapd-db-home-directory /sunone/directory/slapd-sun-lab/db /tmp/nsslapd-db - 3 -

31 .A megoldás értékelés, kitekintés.metací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..synctool 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

32 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/x, 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