昨今の携帯電話の性能向上、アクセス数の向上、コンテンツのリッチ化により『x-Servlet』への性能向上に対する要望が数多く挙がっておりました。
それらに対応するため、『x-Servlet』のバージョン「2.8.3」および「2.8.2」ではキャッシュ機能を見直すことで消費メモリの安定化を追及してまいりました。
(参照：キャッシュ機能効率化)

今回のテクニカルノートでは消費メモリの安定化に対する検証に加え、パフォーマンスチューニングの一手法としてメモリ使用量を減らす方法について紹介させていただきます。

『x-Servlet 2.8.3』がリリースされ既にご利用されている方もいるかと思いますが、それ以外の方にもご参考いただければ幸いです。

【注意】
本テクニカルノートは「キャッシュ上限の見直し」「動的コンテンツにおけるメモリ効率向上」機能の検証のため、下記の擬似動的コンテンツ１ページに対してJMeterによる負荷テストを行い、使用メモリの推移比較とスループットの比較を行っています。

今回の計測結果は弊社環境での結果であり、実環境での結果を保証するものではございません。お客様の運用環境でのバージョンアップや設定変更の際には、十分な検証を行っていただけますようお願いします。

ハードウェア構成

x-Servlet Enterprise Edition	CPU：	Xeon 5160 3GHz（Woodcrest）
	メモリ：	3GB
	OS：	RedHat Enterprise Linux 5.5

Webサーバ	CPU：	Pentium4 3GHz
	メモリ：	3GB
	OS：	CentOS 4.7

負荷生成PC	CPU：	Xeon W3520 2.66GHz（Nehalem-WS）
	メモリ：	8GB
	OS：	Windows 2003 Server

コンテンツ内容

ソース：	iモードXHTML 1ページ（約7KB）
画像：	JPG 13枚（計 約41KB）
出力：	動的コンテンツ（キャッシュ機能OFF）

想定負荷定義

• 負荷が低い状態：10ユーザが同時にアクセスし5秒間隔で100ページを閲覧
• 負荷が高い状態：80ユーザが同時にアクセスし5秒間隔で100ページを閲覧

はじめに、「2.8.2」と「2.8.3」で追加された消費メモリの安定化が、どの程度効果があるかを『x-Servlet 2.8.1』と比較してみましょう。
※このテストでの『x-Servlet』への割当メモリは、デフォルト最大値である 512MB で行っています。

まずは、「負荷が低い状態」での比較。（平常時のアクセスや、夜間のアクセスを想定しています）

	スループット(PV/sec)	レスポンスタイム(ms)
2.8.1	2.0	112
2.8.3	2.0	115

この状態では「2.8.1」と「2.8.3」に大きな違いは無いことがわかります。

次に、「負荷が高い状態」で比較してみます。（突発的なアクセス集中などを想定しています）

	スループット(PV/sec)	レスポンスタイム(ms)
2.8.1	1.70	30,902
2.8.3	11.60	1,712

※この状態の「2.8.1」では、8割のリクエストがタイムアウト(60秒)エラーとなっています。

「2.8.1」ではガベージコレクション(以下GC)でのメモリ開放量が少ないため FullGC が頻繁に発生しています。その結果、処理に必要なメモリが確保できなくなりリクエストの滞留が起きて殆どのリクエストがタイムアウトしています。処理できたリクエストもレスポンスまで30秒と遅延が発生しています。
「2.8.3」ではキャッシュ機能の見直しにより消費メモリの安定化を図っています。そのためGCによるメモリ開放量が多くなり FullGC の頻度も下がっています。その結果、処理が正常に行われ、レスポンスの遅延についても約2秒と最低限となっています。

現在、アクセス集中などでメモリに不安を覚えている方は「2.8.3」によって解決できる可能性があります。是非ご検討ください。

上記で「2.8.3」のメモリ推移を挙げましたが、「2.8.1」に比べれば格段に少なくなっていますが FullGC の頻度は多く、使用メモリも限界に近い。そのような状態では、更なる高負荷には耐えられずレスポンスが悪化する恐れがあります。
それに備えるために、設定変更によるチューニングを試してみましょう。

※以降のテストは「負荷が高い状態」で行っています。

１．搭載メモリに余裕があるならば『x-Servlet 2.8.3』へのメモリ割当を増やしてみます。

	スループット(PV/sec)	レスポンスタイム(ms)
512MB	11.60	1,712
1024MB	15.40	179
1536MB	15.40	196

割当メモリを引き上げることで、FullGC の発生頻度が下がっています。その結果、レスポンスタイムも「負荷が低い状態」と同等近くまで下がっておりメモリにも余裕が出てきました。
また、表からもわかりますが割当が 1024MB と 1536MB で性能に変化はありません。そのため、今回の負荷であれば 1024MB の割当で問題ないといえます。
ただし瞬間的にでも更なる高負荷が考えられるのであれば、1536MB を割当てるのが安全だといえます。

２．『x-Servlet 2.8.3』のキャッシュ設定(*)をチューニングしてみます。

*『x-Servlet』のキャッシュ機能は、「セッション情報」「text/html」「画像」「Flashコンテンツ」をキャッシュしますが、今回の負荷テストで用いた動的コンテンツの場合、「text/html」「画像」「Flashコンテンツ」はキャッシュされず、「セッション情報」に対してのみ有効になります。

まずは、セッション保持数に当たる sessionMaxCount を初期値の 3000 から １/10 の 300 にしてみます。（効果を明確にするため極端な設定とし、割当メモリは 512MB に戻しています）
負荷が高い場合、sessionMaxCount を下げることで有効なセッションが破棄される確率が上がるため、実環境ではサービスレベルとのトレードオフにご留意ください。

	スループット(PV/sec)	レスポンスタイム(ms)
初期設定	11.60	1,712
保持数1/10	15.40	171

セッション保持数を減らすことで、割当メモリを引き上げた時と同様に FullGC の発生頻度が下がり、レスポンスタイムも負荷が低い時と同等近くまで下がっています。

ここまでは『x-Servlet 2.8.3』でテストしてきましたが、同じ設定変更が「2.8.1」でどこまで有効なのかも見てみましょう。
まず、「メモリ割当て引き上げチューニング」での比較です。

	スループット(PV/sec)	レスポンスタイム(ms)
2.8.1(512MB)	1.70	30,902
2.8.1(1536MB)	7.50	5,428
2.8.3(1536MB)	15.40	196

メモリの割当を 1536MB にすることで、「2.8.1」でもエラーの発生はなくなりますがレスポンスの遅延は残ります。「2.8.3」との違いも割当が 512MB のときと同様に顕著となっています。

次に、「セッション保持数の引き下げチューニング」での比較してみましょう。

	スループット(PV/sec)	レスポンスタイム(ms)
2.8.1(初期設定)	1.70	30,902
2.8.1(保持数1/10)	15.10	269
2.8.3(保持数1/10)	15.40	171

こちらのチューニングでは「2.8.1」でも「2.8.3」と同等の効果が期待できます。ただ、「2.8.3」にはまだ余裕があり更なる高負荷にも耐えられそうです。