• 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í.

• Dual Core 3,16GHz
• 8GB DDR2
• 1TB RAID 10

• Windows Server 2008 R2 Enterprise Edition
• IIS 7
• MSSQL Server 2008
• Net Framework 3.5

• Používáme klasickou trřívrstvou architekturu.
  • DB - Database
  • BL - Business logic
  • UI - User interface

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

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čí.

1. 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.
2. 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.
3. 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.

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

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

* Došlo k přehlcení systému, nepodařilo se ani vygenerovat potřebné množství požadavků.

* Došlo k přehlcení systému, nepodařilo se ani vygenerovat potřebné množství požadavků.

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