 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 | ||||||||||||
|
||||||||||||
| JBossの場合 | ||||||||||||
|
次にJBossについて見ていきましょう。  図12：JBoss同期／非同期、1KB、レスポンスタイム  図13：JBoss同期／非同期、1KB、スループット  図14：JBoss同期／非同期、100KB、レスポンスタイム  図15：JBoss同期／非同期、100KB、スループット 一方JBossではセッションオブジェクトが1KBのケースでは非同期が好成績だったものの、100KBのケースではむしろ同期より遅く、200ユーザではテスト中レスポンスタイムが悪化していき、最終的にOutOfMemoryErrorが発生する事態となりました。このため200ユーザ時の値は測定不能としています。 これはレプリケーションの処理が追いつかず、ヒープにオブジェクトが積み重なっていったためだと思われます。同期レプリケーションの場合はOutOfMemoryErrorも発生しませんでしたが、これは同期処理することによりレプリケーション処理が積み重なることを避けられたためだと考えられます。 |
||||||||||||
| まとめ | ||||||||||||
|
今回のテストにおいて、WebLogicはレプリケーションによるパフォーマンスの劣化をほぼ見せませんでした。Tomcatは高トランザクションかつセッションオブジェクトサイズが大きい場合のみパフォーマンスの劣化があらわれましたが、そのほかはWebLogicと同等のパフォーマンスを発揮したといえます。 一方JBossは、同期／非同期共にTomcat／WebLogicには差をつけられた印象です。特に同時アクセスユーザ数が多い場合は、「セッションレプリケーションを採用すべきか否か」の点から検討したほうがよいでしょう。また、デフォルトの非同期レプリケーションではトランザクション量次第でOutOfMemoryErrorが発生するリスクもありますので、同期レプリケーションの使用をお勧めします。 本連載では番外編「JBossクラスタのチューニング」としてJBossにさらにチューニングを行い、パフォーマンスがどこまで伸びるかを検証します。 今回のテストはあくまでもサンプルの簡単なWebアプリケーションに対して行ったものであり、実際にアプリケーションを本番環境に適用する際には十分な負荷テストを行うことをお勧めします。 次回はアプリケーションサーバの機能面での比較を行っていきます。 |
||||||||||||
|
前のページ 1 2 3 4 |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
