 |
||||||||||||||
|
||||||||||||||
| 1 2 3 4 次のページ | ||||||||||||||
|
||||||||||||||
| はじめに | ||||||||||||||
|
これまでTomcat、JBoss、WebLogicの3製品のクラスタリング機能について解説してきました。今回はこの3製品のHTTPセッションレプリケーションのパフォーマンス比較を行います。 |
||||||||||||||
| テスト環境 | ||||||||||||||
|
比較対象となる3つのアプリケーションサーバでクラスタ環境を構築し、Webアプリケーションをデプロイします。アプリケーションはHTTPセッションレプリケーションを行うように設定しておきます。そして負荷テストを行い、各アプリケーションサーバの性能を比較していきます。 テスト用アプリケーションはシンプルなサーブレットです。リクエストを受け付けるとHTTPセッションのsetAttributeメソッドを呼び出し、HTTPセッションに任意のサイズのオブジェクトを格納した上で、クライアントにレスポンスを返します。 クラスタ環境は3台のサーバを用い、そのうち2台でアプリケーションサーバのクラスタを構築し、もう1台がロードバランサとなります。ロードバランサはApacheで、Tomcat／JBoss用にはmod_jk、WebLogic用にはmod_wlを用いて負荷分散を行います。WebLogicの場合、クラスタノードのほかに管理サーバのインスタンスが必要になりますが、管理サーバのインスタンスはクラスタ用サーバの片方に同居させます（注1）。
※注1：
構成としては不均衡になってしまいますが、ほかの製品と平等に「2台のサーバでクラスタを構成」という条件を満たすためにこのようになりました。
 図1：クラスタ環境（Tomcat）  図2：クラスタ環境（JBoss）  図3：クラスタ環境（WebLogic） レプリケーションの設定は「同期（注2）」「ATTRIBUTE単位」で、「setAttributeが呼ばれたオブジェクトのみレプリケーションを実行」とします。よって、各アプリケーションサーバの設定は以下のようになります。
※注2：
「同期」とは「レプリケーションを実行した後にクライアントにレスポンスを返す」という方式です。WebLogicはこの方式で、かつ非同期に切り替えるオプションを持たないため、今回の検証では同期方式で比較を行います。
|
||||||||||||||
|
||||||||||||||
表1：アプリケーションサーバの設定 |
||||||||||||||
|
設定方法の詳細は本連載の第1回（Tomcat）、第3回（JBoss）を参照してください。 アプリケーションへのアクセスにはJMeterを用い、ユーザ数を1から200まで増やしてレスポンスタイムとスループットを測定しました。アクセス間隔は500msとしています。 テストを行うハードウェアのスペックは以下のようになります（3台とも同じです）。
表2：ハードウェアのスペック
テストを行うソフトウェアのバージョンは以下のようになります。
表3：ソフトウェアのバージョン（クラスタサーバ2台）
各アプリケーションサーバはSun MicrosystemsのJDK 1.4.2で動作します。
表4：ロードバランサとテストクライアント
|
||||||||||||||
| チューニング | ||||||||||||||
|
各アプリケーションサーバを実行するJavaのヒープサイズを1024MBとしました（-Xms1024m -Xmx1024m）。アプリケーションを動作させるスレッド数は、WebLogicではプロダクションモードのデフォルトである25としています。 一方Tomcat／JBossとApacheを連携するmod_jkは、Apacheからの接続を維持しつづけるアーキテクチャを前提としていますので、同時接続数にあわせてserver.xmlのmaxThreads属性をチューニングする必要があります。今回は同時にApacheから接続し得る最大数である200としました。
※注3：
このテストは特定ベンダーなどにスポンサリングされていない、独立なベンチマークです
|
||||||||||||||
|
||||||||||||||
|
1 2 3 4 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
