U P O R A B N A I N F O R M A T I K A164 2016 - πtevilka 4 - letnik XXIV ZNANSTVENI PRISPEVKI 1Primoæ Kastelic, 2Mirjana KljajiÊ Borπtnar, 3Robert Leskovar 13GEN, d. o. o. 2,3Univerza v Mariboru, Fakulteta za organizacijske vede, KidriËeva cesta 55a, 4000 Kranj primoz.kastelic@3gen.si; mirjana.kljajic@fov.uni-mb.si; robert.leskovar@fov.uni-mb.si 1 UVOD V zadnjih letih se je uporaba raËunalniπtva v oblaku razπirila na razliËna podroËja. To je pripeljalo tudi v poveËanje πtevila aplikacij, ki delno ali popolnoma teËejo v oblaku (Gomez Saez, Andrikopoulos, Leymann in Strauch, 2015). V Sloveniji smo decembra 2015 vzpostavili sistem dræavnega raËunalniπtva v oblaku. Dræavni raËunalniπki oblak (DRO) je namenska raËunalniπka infrastruktura v lasti in upravljanju dræave, ki omogoËa dræavnim institucijam (neposrednim proraËunskim uporabnikom), da z uporabo koncepta raËunalniπtva v oblaku hitro in poceni doseæejo svoje poslovne cilje. Ponuja raËun- ske, shranjevalne, razvojne, poslovne in druge zmogljivosti v obliki storitev (Dræavni raËunalniπki oblak, MJU, 2015). Carinski informacijski sistem je ravno v fazi prenove, aplika- cije se selijo na viπje verzije aplikativne in sistemske pro- gramske opreme, istoËasno pa poteka tudi selitev streænikov z IBM 2097 z10 (IBM System z10 EC, 2013) na virtualizirano arhitekturo Intel/Linux. Eden prvih uporabnikov DRO bosta ravno FinanËna uprava Republike Slovenije in Slovenski ca- rinski informacijski sistem (SICIS). Ker selitev na arhitekturo Intel/Linux æe poteka in se bodo kasneje v DRO prenesli æe delujoËi vir- tualni stroji, poznamo prepustnost, zanesljivost in razpoloæljivost æe pred prenosom. Spoznavanje last- nosti sistema je temeljnega pomena za razumevanje Razvoj obremenitvenih testov z odprtokodnim orodjem JMeter IzvleËek V prispevku je prikazano obremenitveno testiranje informacijskega sistema z odprtokodnim orodjem JMeter v distribuirani testni arhitekturi. Objekt testiranja je obsegal skupek πtirinivojskih aplikacij, pri Ëemer smo uporabili pet virtualnih strojev, dva virtualna stroja za IBM Websphere Portal, dva za aplikacijski streænik IBM Websphere Application Server in enega za delilnik bremena HAProxy. Definirali smo tri testirne scenarije in tri testirne primere za vsak scenarij. Posamezni testirni primeri predvidevajo razliËno πtevilo generiranih uporabnikov (50, 75, 100, 200, 300 in 500), razliËno dinamiko generiranja uporabnikov (v 10 s, 60 s, 120 s, 240 s in 360 s) ter Ëase izvajanja testov med 57 in 728 s. Rezultati izvedenega testiranja omogoËajo, da skupek testiranih spletnih aplikacij prenesemo v produkcijsko okolje. KljuËne besede: obremenitveno testiranje, Apache JMeter, upravljanje informacijskih sistemov, IEEE 829-2008. Abstract Load test development via the JMeter open-source software The article outlines the IT system load testing using the Apache JMeter open source software tool in a distributed test architecture. The testing object consisted of a set of 4-level applications. In testing, we used 5 virtual machines, two IBM Websphere Portal virtual machines, two IBM Websphere Application Server virtual machines and one HAProxy load balancer virtual machine. Furthermore, for each scenario, we defined three test scenarios and three test cases. Individual test cases provide for different numbers of generated users (50, 75, 100, 200, 300 and 500), different user generation dynamics (10s, 60s, 120s, 240s) and running test times between 57s and 728s. All test cases have shown that the response time was appropriate and memory consumption will not exceed the allocated limits. Based on such results of testing, we can deploy the set of applications in a production environment. Keywords: load testing, Apache JMeter, information systems management, IEEE 829-2008. U P O R A B N A I N F O R M A T I K A 1652016 - πtevilka 4 - letnik XXIV Primoæ Kastelic, Mirjana KljajiÊ Borπtnar, Robert Leskovar: Razvoj obremenitvenih testov z odprtokodnim orodjem JMeter njegovega delovanja ter izbiro ustreznih metod za preuËevanje njegovega obnaπanja (KljajiÊ, 1994). Informacijski sistem je slovenska carinska admi- nistracija poimenovala Slovenski carinski informacij- ski sistem − portal SICIS (angl. Slovenian customs in- formation system). Znotraj portala SICIS sedaj deluje veË sistemov. Carinska Uprava RS je æe od samega zaËetka stremela k temu, da bi bil informacijski sis- tem Ëim bolj uËinkovit. PoslediËno so se zaËeli razvi- jati razliËni podsistemi, ki poveËujejo njegovo funkci- onalnost. Takπni podsistemi so (Informacijski sistem Carinske uprave RS, 2015):  sistem ECS (angl. export control system), ki je podsistem sistema SIAES ter sluæi dokazovanju izstopa blaga iz Skupnosti;  sistem poslovnih pravil, ki skrbi in opozarja na pravilnost izpolnjevanja deklaracij skladno s Carinskim zakonikom Skupnosti, Zakonom o upravnem postopku ipd.;  sistem analize tveganja, katerega naloga je, da identificira tvegane poπiljke, ki jih pooblaπËene uradne osebe ustrezno kontrolirajo;  sistem EORI (angl. economic operator identifica- tion number), ki preverja EORI πtevilke gospo- darskih subjektov.  sistem GCUKOD, ki preverja zneske garancij go- spodarskih subjektov. Ogrodje SICIS sestavljajo πtiri kljuËne arhitektur- ne komponente:  IBM Websphere Portal,  IBM Websphere Application Server,  Oracle DB,  IBM Websphere Message Broker in IBM Web- sphere Message Queue. Testni sistem smo zgradili z namenom selitve ob- stojeËega informacijskega sistema na nove in boljπe tehnologije. Da bi testni sistem deloval po priËako- vanjih, brez odpovedi in z optimalno porabljenimi viri, smo poskuπali omiliti morebitna odstopanja s cikliËnim ponavljanjem testiranja, analiziranja in po- novnega nastavljanja sistema. Nad novim testnim sistemom smo izvajali razliËne tehnike testiranja, ki so podlaga za zbiranje podatkov z opazovanjem in preverjanjem aplikacijskih dnevnikov, streæniπkih dnevnikov in odzivnih Ëasov na delilniku bremena ter z opazovanjem in preverjanjem dnevnikov ter po- roËil orodij za izvajanje testov. 2 METODOLOGIJA DELA Cilji raziskave so:  predstaviti odprtokodno orodje Apache JMeter,  izdelati testirno dokumentacijo v skladu s stan- dardom testiranja IEEE 829-2008,  testirati informacijski sistem SICIS z obremenitve- nimi testi,  dokumentirati izvedbo in zakljuËek testiranja in  oceniti, ali je informacijski sistem SICIS zrel za uporabo v produkcijskem okolju. V Ëlanku se ukvarjamo z raziskovalnim pod- roËjem obremenitvenega in stresnega testiranja. Te- oretiËni okvir testiranja smo obdelali s poglobljenim preuËevanjem tuje in domaËe literature ter preuËeva- njem æe delujoËih sistemov. Na podlagi pridobljene- ga znanja smo izdelali tudi testirno dokumentacijo v skladu s standardom IEEE 829-2008 (angl. Stan- dard for software and system test documentation) in izved li obremenitveno testiranje informacijskega sistema SICIS. Obremenitveno testiranje je uËinkovita metoda za izboljπanje zanesljivosti nekega produkta. Slabosti, ki jih pri proizvodnji ni mogoËe zaznati, lahko kasneje povzroËijo odpoved. Stresno testiranje nam omogoËi, da nevidne napake postanejo vidne in jih lahko opa- zimo in popravimo (Chan, 1995). Obremenitveno testiranje je posebna vrsta testira- nja zmogljivosti, pri katerem ugotavljamo (merimo) robustnost, razpoloæljivost, zanesljivost, odzivnost in podobne karakteristike. Uporabljamo ga za ugotav- ljanje obnaπanja nekega sistema pri normalni in pri poveËani obremenitvi. PoveËana uporaba je vnaprej doloËena tako z volumnom (velikostjo) in hitrostjo zahtev, kot tudi s Ëasovno dinamiko. Obremenitveno testiranje pomaga ugotoviti: a) kakπna je maksimalna prepustnost, b) kje so ozka grla in c) kateri element sistema jo povzroËi. Ko se obremenitev poveËa nad meje normalnega delovanja, govorimo o stresnem testiranju (Erinle, 2013). Priljubljenost obremenitvenega testiranja spletnih aplikacij v svetovnem merilu naraπËa, kar dokazujejo tudi πtevilni tuji Ëlanki, ki opisujejo to problematiko. V nadaljevanju so predstavljene izbrane raziskave. Kiran, Mohaparta in Swamy (2015) so v svoji πtudiji uporabili orodje JMeter kot uËinkovito orod- je za izvajanje obremenitve doloËenemu sistemu. Uporabili so tehniko distribuiranega testiranja. Te- ste so cikliËno ponavljali, vmes so popravljali πtevilo U P O R A B N A I N F O R M A T I K A166 2016 - πtevilka 4 - letnik XXIV Primoæ Kastelic, Mirjana KljajiÊ Borπtnar, Robert Leskovar: Razvoj obremenitvenih testov z odprtokodnim orodjem JMeter uporabnikov, izstrelne Ëase ter parametre sistema. Rezultate so analizirali z orodjem JMeter. Avtorji Jing, Lan, Hongyuan, Yuqiang in Guizhen (2010) v svojem delu obravnavajo simulacijo staranja raËunalniπkega sistema. Kot orodje za obremenjeva- nje so uporabili JMeter v distribuirani arhitekturi, s katerim so poganjali dva scenarija. Pri prvem scena- riju so moËno obremenjevali statiËne strani, pri dru- gem streænik J2EE Tomcat in MYSQL kot bazo po- datkov. Kazalnike obremenjenih sistemov so dobili neposredno s podroËja, katerega vrednosti so shran- jevali na dve sekundi. Wu in Wang (2010) v prispevku govorita, kako strm je trend naraπËanja aplikacij J2EE (v to katego- rijo spadajo tudi aplikacije IBM WebSphere). Avtorja navajata, kateri sistemski parametri lahko vplivajo na boljπe delovanje takih aplikacij. Sem spada pred- vsem velikost javanske kopice. Odsvetujeta aplika- cijski streænik in bazni streænik na istem stroju. Kakor æe pri zgoraj omenjenih delih sta tudi Wu in Wang za testiranje uporabila orodje JMeter v distribuirani ar- hitekturi in nad sistemom izvajala vrsto testov, kate- rim sta spreminjala parametre. »lanek jasno pokaæe pozitivni uËinek apliciranja predlaganih sprememb nad ciljnim sistemom J2EE. Avtorji v svojih delih obremenitveno testiranje uporabijo kot metodo, s katero ugotavljajo, da njihov predmet testiranja pod moËnimi obremenitvami res poËne to, za kar je narejen. 2.1 Orodje za testiranje in naËin testiranja Kot orodje za poganjanje testov smo uporabili odpr- tokodni in prosto dostopni Apache JMeter (Apache JMeter, 2015). Apache JMeter lahko uporabljamo za testiranje uËinka tako statiËnih kot dinamiËnih virov. Uporabljamo ga lahko za simuliranje moËne obreme- nitve streænika ter mreænih virov, na podlagi Ëesar analiziramo delovanje sistema pod razliËnimi pogoji. To orodje je namenjeno doloËenim testiranjem siste- ma (npr. stresno testiranje) in testiranju uËinkovitosti (πtevilo obdelanih zahtev na Ëasovno enoto) (Halili, 2008). Korake, ki so potrebni za izvajanje testiranja, lahko strnemo v naslednje toËke:  identificiramo testno okolje,  identificiramo kriterij(e) uspeπnosti,  naËrtujemo in kreiramo testirne naËrte oz. testirne primere,  kreiramo testirno okolje,  izvedemo testirne naËrte oz. testirne primere,  analiziramo rezultate,  posodobimo testirne naËrte/primere in spreme- nimo parametre opazovanega sistema oz. progra- ma. Objekt testiranja je SICIS. Primere testiranja veËnivojske spletne aplikacije so obravnavali πtevilni avtorji (Iyer, Gupta in Johri, 2005). Pri poganjanju testov je treba paziti, da ozko grlo ne postane raËu- nalnik, na katerem testiramo. Pri naπem delu smo se temu izognili tako, da smo uporabili naËin distribu- iranega testiranja. Slika 1 prikazuje naπo arhitekturo testiranja. Na tri raËunalnike smo namestili orodje JMeter, dva identiËna raËunalnika sta delovala kot podrejena (angl. slave), prenosnik pa smo namenili za nadzor izvajanja testov in prikaz rezultatov, imel pa je tudi vlogo gospodarja (angl. master). Karakteri- stike raËunalnikov so:  enkrat OSX 10.11.2, MacBook Pro (Retina 13-inch), 2,5 GHz Intel Core i5, 8GB RAM,  dvakrat Intel Linux 64, Lenovo ThinkCenter, 3,2 GHz Intel Core i5, 8GB RAM. Slika 1: Distribuirana testna arhitektura z orodjem JMeter U P O R A B N A I N F O R M A T I K A 1672016 - πtevilka 4 - letnik XXIV Primoæ Kastelic, Mirjana KljajiÊ Borπtnar, Robert Leskovar: Razvoj obremenitvenih testov z odprtokodnim orodjem JMeter 2.2 Testirni sistem Testirali smo skupek aplikacij, ki so zgrajene πtirinivojsko (uporabnik, predstavitveni nivo, po- slovni nivo in podatkovni nivo). Za implementaci- jo testirne arhitekture smo uporabili pet virtualnih strojev, osnovanih na Linuxovem jedrnem modulu (KVM, angl. Karnel-based Virtual Maschine), z na- slednjimi karakteristikami:  dvakrat Intel Linux 64 + IBM Websphere Portal 8.5.5, KVM 8GB RAM, CPU 4 socket, 1 core per socket, Intel Xeon CPU E5-2670, 2.60 GHz,  dvakrat Intel Linux 64 + IBM Websphere Applica- tion Server 8.5.6, KVM 8GB RAM, CPU 4 socket, 1 core per socket, Intel Xeon CPU E5-2670, 2.60 GHz,  enkrat Intel Linux 64 + HAProxy 1.6.2 load ba- lancer, KVM 8GB RAM, CPU 4 socket, 1 core per socket, Intel Xeon CPU E5-2670, 2.60 GHz. Testirna arhitektura je prikazana na sliki 2. Podat- kovna zbirka Oracle 12c in streænik IBM Websphere Message Queue (MQ) nista bila predmet testiranja, zato smo ju na sliki prikazali Ërtkano. Delilnik bre- mena je zaradi preglednosti sheme prikazan dvakrat, fiziËno pa je to en virtualni stroj, ki deli zahtevke, na- menjene portalnim aplikacijam na IBM Websphere Portal, in zahtevke, namenjene zalednim servisom, ki teËejo na streænikih IBM Websphere Application Server (WAS). Kot delilnik bremena smo uporabili odprtokodno reπitev HAProxy. HAProxy omogoËa prπenje sed- mega, t. i. aplikacijskega sloja (The OSI Model's …, 2015). V veËini primerov administratorji uporabijo HAProxy in HTTP prπenje povsod tam, kjer je zahte- vana visoka razpoloæljivost kot nuja zaradi neprekin- jenega poslovanja (Levine, 2015). Pri postavitvi testnega okolja smo se oprli tudi na πtudijo redundanËnega postavljanja podatkov- nih centrov (Redundancy …, 2015). Za testno oko- lje smo izbrali postavitev 2N, pri Ëemer je N sklop streænikov, ki so potrebni za normalno obratovanje, in 2N podvojeni, redundanËno postavljeni sistem. 2.3 Testirni scenariji Pod pojmom scenarij si predstavljamo delo enega upo- rabnika, ki se prijavi v portal, nato izvaja operacije od manj zahtevne do zelo zahtevne, na koncu pa se tudi odjavi iz portala. Pri pisanju testnih scenarijev smo upoπtevali raznolikost obremenitve. Scenarije smo razdelili na tri razrede z oznakami SC1, SC2 in SC3. Vsak razred nam predstavlja en testni scenarij. Razred smo nato delili naprej na πtevilo uporabnikov in na Ëas razporejenosti prihodov do streænega mesta (angl. ramp up time). V tabeli 1 so prikazani scenariji od SC1 do SC3 s πtevilom uporabnikov in z izstrelnim Ëasom uporabnika ter Ëasom izvajanja testirnega primera. Slika 2: Shematski prikaz testirnega okolja SICIS U P O R A B N A I N F O R M A T I K A168 2016 - πtevilka 4 - letnik XXIV Primoæ Kastelic, Mirjana KljajiÊ Borπtnar, Robert Leskovar: Razvoj obremenitvenih testov z odprtokodnim orodjem JMeter Tabela 1: Prikaz testirnih scenarijev in testirnih primerov Scenarij Testirni primer ©tevilo uporabnikov Izstrelni Ëas (s) »as izvajanja testirnega primera (s) SC1 SC1U50RT10T98 50 10 98 SC1U200RT60T57 200 60 57 SC1U500RT120T131 500 120 131 SC2 SC2U50RT60T112 50 60 112 SC2U200RT120T387 200 120 387 SC2U300RT240T613 300 240 613 SC3 SC3U50RT120T392 50 120 392 SC3U75RT240T540 75 240 540 SC3U100RT360T728 100 360 728 Ustreznost in potrditev scenarija smo preverili tako, da smo izvedli preizkus testa z enim uporab- nikom. Scenarij smo imeli za uspeπen le takrat, ko je bil odstotek napak enak toËno 0. Teste smo izvajali veËkrat zapored, vsako izvajanje testa smo oznaËi- li z identifikacijsko πtevilko. Pazili smo, da smo te- ste vedno izvajali pod enakimi pogoji in z enakimi vhodnimi parametri. Rezultate smo lahko grafiËno spremljali æe med samim delovanjem, vsi rezultati testiranj so se shranjevali in uredili glede na datum in identifikacijsko πtevilko testiranja. Rezultate te- stiranja smo shranjevali v SVN (Apache Subversi- on, 2015), od koder smo kasneje Ërpali podatke za kasnejπe analize. 2.4 Analiza rezultatov testiranja Gradivo za analizo rezultatov lahko razdelimo na naslednje kategorije:  poroËila orodja JMeter,  streæniπki dnevniki,  aplikacijski dnevniki,  sistemski dnevniki,  statistika na delilniku bremena. Zbrane rezultate orodja JMeter smo pregledali, podatke testov istega razreda smo logiËno zdruæevali v tabele. Dobljene rezultate smo primerjali med se- boj. Slika 3 prikazuje primerjavo rezultatov poganja- nja testov SC2. Ker je testni scenarij enak, spreminjajo se samo parametri testa, πtevilo hkratnih uporabni- kov in izstrelni Ëasi, so podatki primerljivi med se- boj. Iz slike je razvidno, kako se s poveËanjem πtevila uporabnikov poveËajo tudi odzivni Ëasi korakov te- stirnega primera. Slika 3: PovpreËni odzivni Ëasi glede na πtevilo uporabnikov in izstrelne Ëase 120000 100000 80000 60000 40000 20000 0 p ov p re Ën i o d zi vn i Ë as v m es ec u koraki scenarija 2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 U P O R A B N A I N F O R M A T I K A 1692016 - πtevilka 4 - letnik XXIV Primoæ Kastelic, Mirjana KljajiÊ Borπtnar, Robert Leskovar: Razvoj obremenitvenih testov z odprtokodnim orodjem JMeter Iz slike 3 razberemo, da izstopata koraka 3 in 5, pri katerih se odzivni Ëasi moËno poveËajo. Slika 4 prikazuje, kako se s poveËanjem πtevila uporabnikov in poveËano obremenitvijo sistema poveËa tudi od- stotek napak posameznega koraka. Slika 5 prikazuje, kakπna je bila procesorska obre- menitev na streænikih med testiranjem s testnim raz- redom SC2U200RT120T387. VeËji del procesorske obremenitve prevzame poslovni sloj aplikacij, kar je Slika 4: Odstotek napak glede na πtevilo uporabnikov in izstrelne Ëase 35,00 % 30,00 % 25,00 % 20,00 % 15,00 % 10,00 % 5,00 % 0,00 % % n ap ak koraki scenarija 2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 razumljivo, saj portalski del predstavlja predstavitve- ni sloj, poslovni sloj − jedro SICIS − pa predstavljajo streæniki IBM Websphere Application Server, tudi kot podatkovni sloj baze podatkov in sporoËilni sistem. Slika 5: Procesorska obremenitev streænikov med izvajanjem testa SC2U300RT240T613 100 90 80 70 60 50 40 30 20 10 0 00:00 00:01 00:02 00:03 00:04 00:05 00:06 00:07 00:08 00:09 00:10 U P O R A B N A I N F O R M A T I K A170 2016 - πtevilka 4 - letnik XXIV Primoæ Kastelic, Mirjana KljajiÊ Borπtnar, Robert Leskovar: Razvoj obremenitvenih testov z odprtokodnim orodjem JMeter Za zajem podatkov o virtualnih strojih smo upo- rabili sistemsko orodje System Activity Report − SAR (SUSE LLC and contributors, 2015). Z orodjem SAR zajemamo vse podatke o sistemu, npr. zasedenost procesorjev, poraba spomina, vhodno-izhodne ope- racije ter podatke o mreænem prometu. Orodje SAR shranjuje podatke o sistemu v datoteke, razporejene po dnevih. Iz teh datotek lahko izluπËimo podatke tudi kasneje, ko smo konËali testiranje. Koristne in- formacije Ërpamo tudi iz dnevnika oz. spletne ad- ministratorske konzole delilnika bremena. V danem trenutku lahko vidimo, ali se zahteve pravilno prπijo glede na nastavljene uteæi, te smo nastavili na 50 odstotkov. Delilnik bremena ima tudi funkcijo kon- trole zalednih streænikov, tako v vsakem trenutku vidimo, ali se zaledni streænik πe odziva, koliko Ëasa je pretek lo od zadnjega testa in koliko Ëasa streænik æe deluje. Na koncu nam ostane πe analiza javanskih kopic (angl. Java heap). Na spletiπËu IBM Knowled- ge Center najdemo napotke, kako optimizirati IBM Websphere Application Server in IBM Websphere Portal, med drugim priporoËajo tudi uporabo IBM Support Assistant (IBM Support Assistant, 2015). Ko streænik pripravimo za analizo, njegovo dnevniπko datoteko naloæimo v orodje in kot rezultat dobimo poroËilo. Primer takega poroËila vidimo na sliki 6. Ta prikazuje statistiko javanske kopice med izvajanjem testa SC2U300RT240T613 na streæniku IBM Web- sphere Application Server πt. 1. S slike 6 je razvidno, da se vrednost kopice v Ëasovnem obdobju giblje malo nad 1,3 GB do prek 1,5 GB. Naπe priporoËilo je, da se zaËetna vrednost kopice nastavi na 1,3 GB, konËna vrednost pa vsaj na 1,5 GB oz. veË, odvisno od sistemskih virov, ki so nam na voljo. 3 SKLEP V prispevku smo obravnavali problem obremenit- venega testiranja. Najprej smo predstavili okolje, ki smo ga izbrali za testiranje z orodjem JMeter, nato smo predstavili metodologijo testiranja ter sistem- sko programsko opremo, s katero smo si pomagali pri analizi. Na koncu smo podali rezultate testiranja in analize. KljuËnega pomena pri testiranju je bilo napisati testne scenarije, ki zagotavljajo Ëim bolj re- alno simulacijo obremenitev. Dobro napisani testni scenariji, izvedeni testi in opravljena analiza nam lahko kasneje sluæijo kot referenca ob spremembah sistemske oz. aplikativne programske opreme, novih virtualnih strojev ter spremembah na strojni opremi. Dobre testne scenarije mora napisati oseba, ki zelo dobro pozna sistem. Pri delu se je izkazalo, da je do- bra praksa tudi sistematiËno zbiranje in oznaËevanje poroËil med testiranjem in odlaganje poroËil v SVN. NaËin, da vsako serijo testiranja oznaËimo z edin- stveno identifikacijsko πtevilko, se je izkazal kot kljuËen. Testne scenarije in testiranje lahko upora- bimo tudi kot analizo flkaj Ëe«, ko s spreminjanjem parametrov testa odgovorimo recimo na vpraπanje, kaj se zgodi, Ëe v istem Ëasovnem obdobju dela pod- vojeno πtevilo uporabnikov. Delilnik bremena v prvi vrsti sluæi kot stroj, ki zahtevke deli med zalednimi streæniki. Med testiranjem smo priπli do ugotovitve, da z raznimi Ëasovnimi omejitvami (angl. timeout) πËitimo zaledne streænike pred zasiËenostjo. Postavi- tev 2N se je v praksi pokazala kot primerna postavi- tev za testno arhitekturo. V produkcijskem okolju bi predlagali postavitev 2N + 1, v nekaterih primerih celo 3N, tako da bi dva sklopa postavili na primarno lokacijo, tretji sklop pa na sekundarno lokacijo kot nadomestni informacijski center, geografsko loËeno. Na zaËetku testiranja je bilo ugotovljeno, da so javan- ske kopice mnogo premajhne za moËno obremenitev, tako da smo na vseh javanski strojih moËno dvigni- li zaËetne vrednosti. Orodje JMeter se je izkazalo za zrelo orodje, ki ga lahko postavimo ob bok podob- nim komercialnim orodjem. Vedenje, kako se infor- macijski sistem obnaπa zdaj in kako se bo obnaπal v prihodnosti, je zaæeleno, tako se je obremenitveno te- stiranje izkazalo nujno kot proces, ki ga je treba vpe- ljati v poslovanje. Slika 6: Primer poroËila orodja IBM Support Assistant U P O R A B N A I N F O R M A T I K A 1712016 - πtevilka 4 - letnik XXIV Primoæ Kastelic, Mirjana KljajiÊ Borπtnar, Robert Leskovar: Razvoj obremenitvenih testov z odprtokodnim orodjem JMeter 4 LITERATURA [1] Apache JMeter. (2015). Dostopno 11. 12. 2015 na http://jme- ter.apache.org/. [2] Apache Subversion. (2015). Dostopno 11. 12. 2015 na https:// subversion.apache.org/. [3] Chan, H. A. (1995). The benefits of stress testing. IEEE Transactions on Components, Packaging, and Manu- facturing Technology: Part A, 18(1), 23−29. http://doi. org/10.1109/95.370730. [4] Dræavni raËunalniπki oblak, MJU. (2015). Dostopno 11. 12. 2015 na http://www.mju.gov.si/si/delovna_podrocja/informa- tika/drzavni_racunalniski_oblak/. [5] Erinle, B. (2013). Performance testing with JMeter 2.9. Bir- mingham, UK: Packt Pub. [6] Gomez Saez, S., Andrikopoulos, V., Leymann, F. in Strauch, S. (2015). Design Support for Performance Aware Dynamic Ap- plication (Re-)Distribution in the Cloud. IEEE Transactions on Services Computing, 8(2), 225−239. http://doi.org/10.1109/ TSC.2014.2381237. [7] Halili, E. H. (2008). Apache JMeter: a practical beginner’s gu- ide to automated testing and performance measurement for your websites. Birmingham, UK: Packt Publ. [8] IBM Support Assistant. (2015). [CT757]. Dostopno 14. 12. 2015 na https://www-01.ibm.com/software/support/isa/. [9] IBM System z10 EC. (2013). [CT555]. Dostopno 11. 12. 2015 na http://www-01.ibm.com/common/ssi/ShowDoc. wss?docURL=/common/ssi/rep_sm/1/897/ENUS2097-_h01/ index.html&lang=en&request_locale=en. [10] Informacijski sistem Carinske uprave RS. (2015). Dostopno 11. 12. 2015 na http://www.fu.gov.si/carina/. [11] Iyer, L. S., Gupta, B. in Johri, N. (2005). Performance, sca- lability and reliability issues in web applications. Industrial Management & Data Systems, 105(5), 561−576. http://doi. org/10.1108/02635570510599959. [12] Jing, Y., Lan, Z., Hongyuan, W., Yuqiang, S. in Guizhen, C. (2010). JMeter-based aging simulation of computing system. V Q. Luo, & X. Ming (ur.), 2010 International Conference on Computer, Mechatronics, Control and Electronic Engineering (CMCE 2010) (vol. 5), Changchun (str. 282−285). IEEE. http:// doi.org/10.1109/CMCE.2010.5609969. [13] Kiran, S., Mohapatra, A. in Swamy, R. (2015). Experiences in performance testing of web applications with Unified Authentication platform using JMeter. V H. A. Bin Sulaiman (ur.), Technology Management and Emerging Technologies (ISTMET), 2015 International Symposium on, Langkawai Island, Malaysia (str. 74−78). IEEE. http://doi.org/10.1109/ ISTMET.2015.7359004. [14] KljajiÊ, M. (1994). Teorija sistemov. Kranj, Slovenija: Moderna organizacija. [15] Levine, S. (2015). Red Hat Enterprise Linux 7 Load Balancer Administration. Red Hat Inc. Dostopno 9. 12. 2015 na https:// access.redhat.com/documentation/en-US/Red_Hat_Enter- prise_Linux/7/pdf/Load_Balancer_Administration/Red_Hat_ Enterprise_Linux-7-Load_Balancer_Administration-en-US. pdf. [16] Redundancy: N+1, N+2 vs. 2N vs. 2N+1. (2014). Dostopno 12. 12. 2015 na https://www.datacenters.com/news/redun- dancy-n1-vs-2n/. [17] SUSE LLC and contributors. (2015). SUSE Linux Enterprise Server 11 SP4 System Analysis and Tuning Guide. SUSE LLC. [18] The OSI Model's Seven Layers Defined and Functions Explai- ned. (2014). Dostopno 9. 12. 2015 na https://support.micro- soft.com/en-us/kb/103884. [19] Wu, Q. in Wang, Y. (2010). Performance Testing and Optimi- zation of J2EE-Based Web Applications. V Z. Hu in Z. Ye (ur.), Proceedings, The Second International Workshop on Educa- tion Technology and Computer Science (ETCS 2010), (vol. 2), Wuhan, China (str. 681−683). Los Alamitos, CA: IEEE. http:// doi.org/10.1109/ETCS.2010.583.  Primoæ Kastelic je veË kot sedemnajst let zaposlen v podjetju 3GEN kot sistemski inæenir. Ukvarja se z integracijo informacijskih sistemov, njihovo varnostjo, zanesljivostjo in razpoloæljivostjo. V podjetju tudi vodi sistemsko skupino za administracijo operacijskih sistemov in upravljanje z aplikacijskimi streæniki.  Mirjana KljajiÊ Borπtnar je docentka za podroËje informacijskih sistemov na Fakulteti za organizacijske vede Univerze v Mariboru. Na dodiplomskem in podi- plomskem πtudiju je nosilka πtevilnih predmetov. Njena raziskovalna podroËja so veËkriterijsko modeliranje, simulacijski modeli za podporo odloËanju, odkrivanje znanja iz podatkov, sistemi za podporo skupinskemu odloËanju in ekspertni sistemi. Za objavljene izsledke eksperimentov na podroËju raziskovanja odloËanja skupin s pomoËjo interaktivnih simulacijskih modelov je s soavtorji prejela veË mednarodnih priznanj. Kot avtorica ali soavtorica je objavljala v mednarodnih znanstvenih revijah in konferencah. Sodelovala je v veË evropskih in nacionalnih projektih. Je Ëlanica programskega odbora blejske eKonference, konference o razvoju organizacijskih znanosti, WorldCIST in drugih, kot recenzentka pa sodeluje na mednarodnih in domaËih konferencah ter revijah.  Robert Leskovar je redni profesor za podroËje informacijskih sistemov in kakovosti na Fakulteti za organizacijske vede Univerze v Mariboru. Njegovo razisko- valno podroËje obsega kakovost in testiranje programske opreme, veËkriterijsko odloËanje in simulacijo sistemov.