“サムライAPサーバ”を選択する視点：アナリストに学ぶ情シストレンド（1/2 ページ）

APサーバには「舶来品」が多い。そのため日本語処理関連で苦労した経験をお持ちの方も少なくないだろう。だが国産APサーバの中には、文字エンコード変換高速化を図り、ユーザーの体感レスポンス改善を図ったものもある。日本の情報システムに最適なAPサーバを選ぶ視点を、アナリストが示す。

[岩上由高（ノークリサーチ），ITmedia]

　「JavaEEベースのアプリケーションサーバ（APサーバ）は？」と問われたら、あなたはどんな名前を挙げるだろうか。商用製品であればWebSphere Application ServerやWebLogic Application Server、オープンソースであればTomcat、Jetty、JBOSSなどを挙げる方が多いかもしれない。ご存知のように、これらはいずれも海外で開発されたプロダクトである。

　APサーバは海外製の独壇場のように感じるが、ミッションクリティカルな案件で実績を積みながら進化してきた国産APサーバも存在する。その1つが日立製作所の「Cosminexus」だ。今回、数年振りのバージョンアップを行い、その中にはさまざまな新機軸が盛り込まれている。

　そこで、本稿では「Cosminexus」が備える機能やサービスを1つの例として取り上げ、最新のAPサーバとJavaVMにどのような工夫が施されているのかを検証する。Cosminexusには、独自のJavaVMを備えるなど、Javaの根幹部分にまで踏み込んだ取り組みが数多く見受けられる。APサーバの現状を探る上ではまさに格好の題材といえる。本稿を通じて、適材適所でのAPサーバとJavaVM選択の良いきっかけとなれば幸いである。

コードはそのまま、実行性能は向上

　Cosminexusのバージョンは現在8であるが、初めて独自のJavaVMを搭載したのはバージョン5の時である。従ってCosminexusのJavaVMの歴史はすでに7年近くに及ぶことになる。もちろん、他社の独自JavaVMと同様にサン・マイクロシステムズからライセンスを受け、互換性テストをクリアしている。こうした独自JavaVMは、Javaコード自体を変更することなく実行性能を上げられる点に特徴がある。

　CosminexusのJavaVMには以下のような改善が施されている。

・Unicode(内部コード)とShift_JISやEUC（入出力コード）間の文字エンコード変換高速化

・Dateクラスの各メソッドの高速化

・URLEncode/Decodeの高速化

・StringBuffer.append()の処理ロジック改善

・valueOfメソッドの処理ロジック改善

・synchronizedブロックの冗長性の改善

　これらの改善点はいずれも実際の利用シーンを想定したものだ。特に日本の開発者にとって重要なのは「Unicode(内部コード)とShift_JISやEUC（入出力コード）間の文字エンコード変換高速化」だろう。Javaだけでなく、内部コードにUnicodeを採用する言語やOSも増えている。だが、実際に作成するコンテンツはまだまだShift_JISやEUCを採用するケースも多く、必然的にnew String()とgetBytes()によるコード変換ロジックが多用されることになる。文字エンコード変換の高速化は、国産ベンダーである日立製作所ならではの改善といえる。

　その処理性能を測定してみたのが、以下のグラフである。テストコードによるベンチマークテストでは通常のHotSpotJVM（グラフの「Sun JDK5.Ou15」と「Sun JDK6.ou06」）とCosminexusのJavaVM（グラフの「日立JDK 07-50-03」）との処理性能比較で大きな差が出た。

Linux（画像＝左）、Windows XP（画像＝右）での文字エンコード変換処理性能比較（いずれも画像クリックで拡大）

　処理Aは26文字のASCII文字列を200万回newするのに要した時間、処理Bは上記インスタンスを200万回getBytes()するのに要した時間をそれぞれ測定したものだ。こうした処理は1回のリクエスト／レスポンスにおいても頻繁に呼び出されるため、上記結果がユーザーの体感レスポンスにも大きな影響を与えることはいうまでもない。

　このように現在利用しているJavaVMにどのような工夫が施されているかを知れば、自分自身でロジックを工夫すべき箇所とJavaVMに任せるべき箇所を意識するなど、より深みのあるコーディングに役立てられる。