|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
| テスト結果 | ||||||||||||
|
まず、セッションに格納するオブジェクトのサイズを1KBとし、テストを行いました。 ![]() 図4:同期、1KB、レスポンスタイム ![]() 図5:同期、1KB、スループット 50ユーザ程度まではどの製品も同等のレスポンスタイム、スループットを達成していますが、JBossでは100ユーザ以降レスポンスタイムが膨れ上がり、スループットが頭打ちになっています。Tomcat、WebLogicは共にレプリケーションの影響を意識せずにスケールしているといえます。 |
||||||||||||
| セッションに格納するオブジェクトのサイズを100KBとした場合 | ||||||||||||
|
続いてセッションに格納するオブジェクトのサイズを100KBとし、テストを行いました。Webアプリケーションが利用するセッションのサイズとしてはかなり大きい部類でしょう。これより大きいサイズのオブジェクトを利用するような場合は設計の見直しをお勧めします。 ![]() 図6:同期、100KB、レスポンスタイム ![]() 図7:同期、100KB、スループット 今回も100ユーザあたりまではTomcat、WebLogicの両者がレプリケーションの影響を感じさせないレスポンスタイム/スループットをだしていますが、200ユーザで差が開き、WebLogicのほうがよい成績を残しています。 一方JBossは50ユーザからレスポンスタイムへの影響が目立ちだしています。200ユーザ時にはレスポンスタイムが3000msに達し、一般的なWebアプリケーションとしても許容時間の限界に来ているといってよいでしょう(このテストアプリケーションはまったくビジネスロジックを持っていないことに留意してください)。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||





