===== Web Services scalability in the cloud ===== ===== Infrastrucure ===== * Testování jsme neprováděli v claudu, ale na aplikačním serveru a localhostu. * Diagram zobrazuje infrastrukturu na které jseme prováděli testování. {{infrastructure.png|}} === Server configuration === == Hardware == * Dual Core 3,16GHz * 8GB DDR2 * 1TB RAID 10 == Software == * Windows Server 2008 R2 Enterprise Edition * IIS 7 * MSSQL Server 2008 * Net Framework 3.5 ==== Application architecture ==== * Používáme klasickou trřívrstvou architekturu. * DB - Database * BL - Business logic * UI - User interface {{taskmanagerarchitecture.png|}} ===== Použití sessions a přístupová práva ===== ==== Sessions ==== Rozhodli jsme se použít sessions, pro ukládání informací a o aktuálně přihlášeném uživateli. Při úspěšném provedení metody LogIn jsou do ,systémem ASP.Net přidělené, session uložena data o přihlášeném uživateli. Při každém dotazu na metodu jinou než LogIn je kontrolována session, zda v ní jsou údaje o přihlášení a pokud tam nejsou, tak operace není provedena. Session je identifikována pomocí cookies, což je standartní mechanismus ASP.Net. Původně jsme zvažovali možnost autentifikace pomocí hlaviček v HTTP requestu. Nakonec jsme to ale zamítli, protože mechanismus sessions je jednoduchý na používání, nemusejí se při každém požadavku přenášet tzv. credentials a mechanismus přihlášení/odhlášení je více rozšířený. ==== Práva ==== V systému jsou tři role (admin, manager, user) a každá má přiřazené povolené operace. Na začátku vykonávání každé operace kromě přihlášení a odhlášení se provádí kontrola, zda má aktuální uživatel roli s právem na tu metodu. Pokud nemá, tak se metoda ukončí. ===== Měřené scénáře ===== - Služba GetTasksInProject provádějící operaci READ. Měření se skládá ze 3 operací: LogIn, GetTasksInProject, LogOut. Měří se služba vyžadující přihlášení, je zde tedy využíváno sessions. - Služba CreateProject provádějící operaci CREATE + služba CloseTask provádějící operaci UPDATE. (DELETE není poskytován.) Měření se skládá ze 4 operací: LogIn, CreateProject, CloseTask, LogOut. Opět se využívají sessions. - Služba GetUsersByString hledá předaný řetězec ve loginech a jménech všech uživatelů. Z důvodu malého počtu uživatelů má metoda i druhý parametr - počet opakování hledání. To je z důvodu testování časově náročné operace. Pro účely testování jsme zvolili počet opakování hledání na 10000. ===== Měřicí nástroje ===== Použili jsme program WCAT, dostupný z http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1466 Měření bylo nakonfigurováno následujícími skripty: {{stress-config.zip|}} ===== Výsledky měření ===== Měřena odezva obou služeb umístěných na serveru http://taskmanager.borovicka.name a na lokálním počítači (Intel Core Duo 2 GHz, 2 GB RAM, disk 7200 otáček). ==== 1. scénář - Operace READ ==== ^ počet transakcí [1/s] ^ průměrná odezva [ms] ^^ ^ ^ server ^ localhost ^ | 10 | 14 | 9 | | 40 | 16 | 13 | | 80 | 20 | 49 | | 160 | 73 | 179 | | 320 | 187 | 992 | | 640 | 463 | * | | 1280 | 902 | * | * Došlo k přehlcení systému, nepodařilo se ani vygenerovat potřebné množství požadavků. {{stress1b.png|Graf}} {{stress1a.png|Přiblížení grafu}} ==== 2. scénář - Operace CREATE+UPDATE ==== ^ počet transakcí [1/s] ^ průměrná odezva [ms] ^^ ^ ^ server ^ localhost ^ | 10 | 17 | 13 | | 40 | 19 | 22 | | 80 | 24 | 64 | | 160 | 81 | 205 | | 320 | 203 | 1212 | | 640 | 601 | * | | 1280 | 1745 | * | * Došlo k přehlcení systému, nepodařilo se ani vygenerovat potřebné množství požadavků. {{stress2b.png|Graf závislosti zátěže na počtu transakcí}} {{stress2a.png|Zoom na nižší hodnoty na počátku grafu}} ==== 3. scénář - Operace s vysokou zátěží ==== ^ počet transakcí [1/s] ^ průměrná odezva [ms] ^^ ^ ^ server ^ localhost ^ | 10 | 16 | 17 | | 20 | 28 | 43 | | 30 | 43 | 64 | | 40 | 80 | 115 | | 60 | 152 | 172 | | 80 | 198 | 293 | | 100 | 240 | 418 | {{stress3.png|Graf zátěže}} ===== Závěry z měření ===== Při měření na lokálním stroji jsme narazili na problém přetížení způsobený tím, že zkoumaný server i měřící stanoviště běží na stejném stroji a sdílely systémové prostředky. Potvrdilo se, že server dobře zvládá zátěž okolo 100 transakcí za sekundu. Lokální stroj s horšími parametry byl zákonitě o něco pomalejší, měl při měření pouze výhodu nižší časové prodlevy datového přenosu po síti. Kdyby ale nebylo problému popsaného v prvním odstavci, nebyly by grafy nikterak výrazně odlišné (měly by pouze odlišný sklon), protože oba stroje mají stejný počet výpočetních jader - škálovatelnost je na obou strojích stejná.