Javaアプリケーションサーバのクラスタリング機能比較第8回

TCPスタック

tc5-cluster-service.xmlに記述されているデフォルトのプロトコルスタックはUDPによるマルチキャストベースのものですが、TCPベースのプロトコルスタックで動作させることも可能です。

このプロトコルスタックの例が、tc5-cluster-service.xmlにコメントアウトで記述されています。デフォルトのUDPベースの設定を削除し、TCPベースのプロトコルスタックを有効にした上で、bind_addrとinitial_hostsの各属性を環境にあうように設定します。
tc5-cluster-service.xml：TCPスタック

 

	

	   

	      

	      
	         num_initial_members="3" up_thread="true" down_thread="true"/>

	      

	      

	      

	      
	         retransmit_timeout="3000"/>

	      

	      
	         print_local_addr="true" down_thread="true" up_thread="true"/>

TCPスタック変更後のテスト結果

変更後のテスト結果は以下の通りです。

図9：TCPスタック、1KB、レスポンスタイム

図10：TCPスタック、1KB、スループット

図11：TCPスタック、100KB、レスポンスタイム

図12：TCPスタック、100KB、スループット

セッションオブジェクトが100KBの場合でも大幅な性能向上が見られ、Tomcatの性能に迫る効果をあげています。TCPスタックの設定であればJBossのセッションレプリケーションも性能面の問題がほぼ解消されたといってよいでしょう。

TCPスタックはクラスタノード間をTCPで結ぶことになるため、ノード数が増えると網の目状に接続数が増大します。

図13：ノード数の違いによる接続数の違い

このためノード数が増えた場合はTCPスタックが不利になることも考えられます（その場合は前掲のUDPチューニングを採用してください）。しかし、今回の検証では2ノードのクラスタで良好なパフォーマンスをみせることを証明しました。

終わりに

最新のモジュールとチューニングの組み合わせで、JBossはTomcatに迫る性能をだすことが確認できました。これはオープンソースソフトウェアが日々向上を続けているということの証左といえるかもしれません。

実は今回掲載したテスト以外にもライブラリとチューニングの組み合わせを試しましたが、「古いバージョンのJBossCache+TCPスタック」ではあまり効果が得られませんでした。つまり性能改善にはJBossCacheの差し替えが必須ともいえます。

また依存性の問題はないと記述しましたが、本番への適用においてライブラリの変更を行うことは抵抗のある人も多いでしょう。JBossCache1.2.4が組み込まれるJBossの次のバージョンに期待を寄せています。