Table of Contents
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í.
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ž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ů.
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ů.
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 |
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á.