[Java News] → [Java Performance Tuning] → [no.23] [no.37] [no.38]

Java Performance Tuning Newsletter no. 38

まずは本題からはずれてますが、「まとめ」のコラム書きであり、ここ JavaPerformanceTuning.com の CTO でもある Kirk (Pepperdine) におめでとうを言わせてください。 JDJ 紙のエンタープライズ編集者に指名されたのです。 よくやったね Kirk。増大した業務負荷を楽しんでください。

本題に戻って、今月はふたつのパファーマンスには関連しない記事が目を引きました、どちらの記事から も今や Java がいかに大物になったかを確認できるからです。 ひとつ目として、IT 業界が緩やかに Microsoft の独占から離れつつある様子について The Inquirer サイトで Charlie Demerjian が良くできた話題にしています (The IT industry is shifting away from Microsoft)。 どんなものであれ Microsoft 離れということはクロスプラットフォームな開発が増えることで、それは自然と Java を奨励することと同然なこととして私は彼を信じたいです。 そしてこの動きの速い IT 業界で10年毎に繰り返されてきたようにこれからの 10年で何人かのすごい勝者と何人かのすごい敗者が出現するだろうという事に立ち向かっていきましょう。 Java がすごい勝者のひとりであることには完璧な自信があります、しかし今のところは Microsoft がすごい敗者になることには賭けようとは思いません。 過去の出来事から、Microsofot がこういった状況から抜け出すことについては抜け目めの無いことがわかっていますので、今のところは Microsoft が崩壊するほうに賭けようとは思いません。

二つ目の記事は違った理由で目を引きました。 昔はよく Perl でプログラムを書いていました。 楽しかったしスキルも充分でした、しかし物事に強い型付けをできないことにはがっかりしていました。 他のコードからの呼び出しに制約を持たせる API を用意するやりかたが好きです。 強い型付けを使いたいという場面では Perl の「やりかたはひとつではない」という長所がどうしようもない弱点になっていました。 ですのでちょっとしたスクリプティング以外では Perl をまともには使いません。 しかし物事が置かれている状況についての着想を得るために Adam Turoff の視点「Perl の今」 を目にして興味を持ちました。 興味深い読み物でした、しかし中でも最も興味深かったのは回答もされている「Perl は Java や .NET と勝負できるか?」という質問でした。 これは現在の IT 業界が Java と .NET という二人の巨人に独占されている事のもうひとつの証明です。 勿論他の多くの言語やシステムにも存続の余地はあるものの、これは Java が益々強くなりつつある事のもうひとつの証明なのです。 さてこれで 2004年を素敵に始めることができますね。

ニュースレターではいつも通り大量の記事、ツール、その他 についてお届けします。 いつものセクション全て、さらにお約束の連載記事の 1回目「Fast Fail Iterators」もお届けします。 Kirk のまとめ では「セッションビーンズ」、「分散呼出しの計時」、「ガベージコレクション」等を取り上げます。 今月のインタビュー は JBossCache のプロジェクトリーダである Bela Ban をお迎えします。 そして今月の質問は「J2EE アプリケーションのプロファイリングについて尋ねる」をお届けします。

ジャヴァ・ザ・ハットでは「ワォ!なひととき」と「エージェント・スミス(訳注:映画マトリックスの登場人物)の訪問」、我等が「profiler」氏によるパフォーマンス・チューニング・テクニック漫画の新版、それともちろん簡潔にまとめた沢山の 新しいパフォーマンス・チップス をお届けします。

最新ニュース

Java パフォーマンスチューニング関連ニュース

ツール紹介

最新記事

Jack Shirazi(訳注: メールは英文でどうぞ。)


まとめ

ザ サーバーサイド

(訳註:サーバサイド技術一般に関する情報を集めたウェブサイト)

ご存知ないかもしれませんが、ザ サーバーサイドの装いが新しくなりました。 しかし本当のニュースというのはザ ミドルウェア カンパニーが www.theserverside.com に対応する www.theserverside.net という .NET サイトを立ち上げると決定したことです。 これは他ならぬテッド・ニュワードの先導により行なわれました。 テッドは Java と .NET どちらにも深い経験を持っていますし、双方の技術に関する何冊かの書籍も執筆しました。 さらに、ジャイ・ジンマーマンと共に、"No Fluff, Just Stuff"という Java シンポジウムのレギュラースピーカーでもあり、さらに Java コミュニティプロセスではMedaData 専門家委員会で活躍しています。 そう、テッドは Java オタクでも .NET オタクでもありません。 そのかわり、彼は技術そのものとそれの最善の適用方法についてバランス良く理解しています。 唯一の疑問は、これが Microsoft と Java 技術の成功的橋渡しとなるのか、ザ ミドルウェア カンパニーの Java ペットショップ・パート2となるのかということです。 テッドが舵取りしているのですよ、私は前者に賭けます。

ザ サーバサイドにセッションビーンズを扱っている投稿がふたつあります。 ひとつめのものはステートフルセッションビーンズを使うこととパフォーマンスの関連についてで、ふたつめはステートレスセッションビーンズの使用方法とどうやってサーバアフィニティを獲得するかという質問です。 クライアントがサーバとセッションのコンテキストで対話する時に、しばしば双方がステートを構築するアクションを引き起します。 質問としては、どこでステートが管理されているのかということです。 サーバ上でステートを管理することを回避できるのであれば、ステートレスセッションビーンズを使えるのです。 ステートが部分的であれ全体であれサーバ上で管理されるのであれば、ステートフルセッションビーンズを使わなければなりません。 セッションビーン内にステートを保存しなければならないことの結末というのは、セッションビーンがもはや共有可能ではなくサーバはクライアントとそのクライアントが使うステートフルセッションビーン間のセッションを管理する必要があるということです。 必要なものがステートレスセッションビーンだけなのであれば、サーバはどのようなクライアントに、どのようなビーンでも提供することができます。

この記述からサーバ上でステートを管理することとパフォーマンスの相関性を理解することができます。 まず、とにかく、ステートフルセッションビーンズだけを使うと、サーバに 1 クライアント毎にひとつのステートフルセッションビーンの管理をするように強いることになるのです。大規模システムでは、これで大量のリソースが消費されてしまうことがあります。 かわりにステートレスセッションビーンズを利用できるのであれば、サーバはクライアント全体をサービスするのに必要な数のビーンズを管理すればすみます。 クライアント側ではリクエストを出してからしばらく考えたりして時間が掛るというのが典型的なパターンなので、必要なステートレスセッションビーンズの数はサービス対象のクライアントの数よりずっと少なくなるのです。 最後の一言ですが、セッションビーンズを使えば、サーバアフィニティについて考慮する必要がないと良く理解いただけたかと思います。 ステートフルセッションビーンズの場合はオートマチックです、ステートレスセッションビーンズの場合は必要ありません。

ザ サーバサイドの他の投稿では複数のサーバが関連する場合にどうやってネットワークのラウンドアップ時間を計測すればよいかという質問が上がっていました。 表面的にはこの問題は実にややこしく思えます。 しかし、しばしば 2台のマシン間だけとはいえ、ネットワークのラウントトリップ時間を良く計測します。 コードは概ねこんな感じです:

long beginTime = System.currentTimeMillis();
otherSystem.remoteCall();
long endTime = System.currentTimeMillis();

さて、計測した時間には次のものが含まれます、メソッド呼び出しの時間、パラメータをバイト配列に変換する時間、他システムへ RMI を投げる時間、ネットワーク上の転送時間、バイト配列を読んでパラメータに変換しなおす時間、そこでタスクを実行する時間、そしてそれからこれら一連の処理を逆にして計算結果を戻す時間です。 でもって、リモートメソッドの計算にかかる時間は取り除きたいものです。 大丈夫、サーバ側にこのコードを追加するだけです:

public Object remoteCall() {
  long beginRemoteCall = System.currentTimeMillis();
  dothework();
  long endRemoteCall = System.currentTimeMillis();
}

このふたつの数値からネットワークのラウンドトリップ時間を計算できます(もちろんオーバーヘッドは含まれていますが)。 さて 1台以上のマシンが関連する時はどうすれば良いでしょうか。 投稿されていた推奨方法は同じ手法を下り方向のリモート呼び出しにも適用し続けるというものでした。 全ての数値を集計さえすれば、パフォーマンスの傾向は集計データから抽出できるでしょう。 抽出した傾向を読んで、システムのどの部分にチューニングが必要か決定できるはずです。

The JavaRanch

引き続いて JavaRanch へと移ると、finally を使うことに関するオーバーヘッドについての質問がありました。 質問への回答はありませんでしたが、とても面白いいくつかの指摘がありました。 finally ブロックは、メソッド中で例外が投げられても投げられなくても実行させるべきコードに対して使用します。 たとえば、ストリームやコネクションを finally ブロックで閉じるというのはよい習慣です。 例外が発生したときにコネクションが必ず閉じられるようにしようとしたら、例外ハンドラの中に重複したコードを書く必要がでてきます。 これは DRY原則 (Don't Repeat Yourself==繰り返しを避けよ)に反します。 単純に、DRY原則に従わなければ、コードはより保守しにくくなっていきます。 コードベースにはより多くのコード片が追加されることになり、HotSpot があなたのコードを正しく解析するのを妨げ、コードが最適化されるチャンスを逃してしまうことになります。 サンのエンジニアは、HotSpot のような最適化プログラムが、コーディングスタイルに影響されやすいと認識していて、だからこそ、HotSpot はよいコーディングスタイルを念頭において作られている、ということがその良い証拠です。

同じアプリケーションで、マルチスレッド版よりシングルスレッド版の性能が良いとしたらどんな理由からでしょう? 質問には詳細な条件が添えてあったので、この謎を皆で考えることができるでしょう。 読み込み命令だけを処理するあるスレッドは、通常その実行に 500ms 必要でした。 興味深いのは、そのスレッドが 10個走ったとき、個々のスレッドが完了するのに 5000ms かかったということです。 この非常に怪しい結果は、各スレッドがその完了のために全体の終了を待ちあせているように見えます。 しかし、アプリケーション中には synchronization がまったくありません。 どうやって他のスレッドの実行を邪魔できるというのでしょう? ある提案では、そのアプリケーションが 1CPU で動いていたのだろう、というものです。 すぐに確認がされ、その通りであるとわかりました。 謎は解けました。 次の謎は、なぜそのアプリケーションが、マルチ CPUマシンで動いているのに 1つの CPUしか使っていなかったか、です。 これが回答だ、という回答は出てきませんでしたが、VM がグリーンスレッド(擬似スレッド)を使っていて、ネイティブスレッドを使ってなかったんじゃないか、という仮説が出ました。 これは答えではありませんが、一つの CPU しか使われていなかった、ということが発見されたのは有益でした。

JavaGaming.org

ガーベージコレクター(GC)の性能に関して、ここ以上に興味深いグループがあるでしょうか? 他のどの掲示板と比べても、www.JavaGaming.org には GC とオブジェクト生成についての質問が多いのです。 いつものように、最初の投稿は、ガーベージコレクターと VM の内部メモリ空間が、 たいへん大きなオブジェクトの生成をどう扱っているのか、というものでした。 質問者が尋ねているゲームでは、秒間 30フレームの大きな jpeg を生成していました。 質問内容は、エデンスペースでの GC のコストが低いので、 GC が起動されるまで全フレームを保持できる大きな単一のエデンスペースを用意すべきか、というものでした。 全般的に、GC とトレイン GC の説明が混乱していた箇所があったものの、スレッドは素晴らしいものになりました。 最終結論もまた困惑させられるものでしたが、提示された情報元によれば、よくよく考慮しなければいけない内容だ、ということだけは確かです。 与えられたアドバイス:「ビデオゲームは、非常に小さな Eden を使うべきである」 このアドバイスに従えば、オブジェクトはアプリケーションがより長い GC 時間を要してしまうような、古い世代に直接生成されるということになります。 小さな Eden を使う理由のひとつは、これら大きなオブジェクトを Eden に保持しておくのは不可能に近いので、それらを生存スペースや古い世代へとコピーすることにかかる時間が、GC 自身のコストよりも高くつくかもしれないから、ということです。 この場合、明らかに間違ったアドバイスと思われたものが、完全に間違いとは言い切れないかもしれませんでした。

他の投稿では、Java でマイクロベンチマークを正しく行うことが、以下に困難か、ということを引き続き知ることになりました。 困難さの根源は、HotSpot によって行われる機械的な最適化にあります。 この一連の投稿では、非常に経験に富む開発者達が、ある三角法の計算をするための新しい技法の性能を、マイクロベンチマークで測定するためにどうすればいいか、としているのを目の当たりにしました。 ありがちですが、最初の測定値は、我々が絶対に含めたくはない、コードを最適化するコスト、GCのコスト、 その他もろもろの影響、などを含むものとして出てきました。 出てきたこの数値がおかしいというのは、-Xcomp フラグが異なる結果を出力してきたことで明らかになりました。 そこでは、メソッドをコンパイルする時間がベンチマークに含まれている、というのが明らかに示されていました。 この例外を除去するためには、あらかじめメソッドのキャッシュを効いた状態まで持って行っておく必要があります。

投稿の中で一つ欠けていたのは、統計でした。 平均値、中央値、最大値、最小値、標準偏差、分散、といった値を見れば、マイクロベンチマークの結果が異常かどうかはわかるはずです。 干渉から自由な、よいベンチマークでは、分散や標準偏差は非常に小さく(0が理想値)、平均値、中央値、最大値、最小値は非常に近く(すべて同一、が理想値)なります。 これらの値がピシッと揃った時点で、そのマイクロベンチマークが良いものだ、と言えるのです。

Kirk Pepperdine.


ジャヴァ・ザ・ハット

ワォ!

このコメントを見たときは、「ワォ!」って思ったよ。

Karjoth と Tschudin は、[暗号化された] エージェントのコードが、暗号化された入力を計算して暗号化された出力を出すようにしておき、その出力が復号化されたときは、オリジナルの入力をオリジナルのコードで扱ったのと同じ結果になるようにした。

(エージェントについての この記事) もし暗号化されたデータを扱う必要が出たなら、これは非常に効率のいいやり方なのかもしれない。 こんな風に処理することについて、性能が犠牲になるんじゃないか、とは思うけれど。 それでも、このやりかたは「クールなプログラミング手法」のリストに登録されるべきものだろうな。

軽く紹介

デザインパターンのすごい愉快なパロディみたいなこの本「デートのデザインパターン」 を紹介しておこう。 自分じゃまだ読んでないけど、いずれ読むような気がする。 とりあえずは Amazon でサンプルを読んでみようかな。

ハットの日記

10月15日
俺達はエージェントスミスの訪問を受けた。 マトリックスに出てくる。 知ってるだろ? 黒いサングラス、耳の後ろにワイヤーコイルをひっかけて、機械のような話し方をして、何を考えてるのかよくわからない連中だ。 エージェントスミスは二人来たけど、二人はまったく同じではなかった。 二人には、エージェントその1、その2 という名前をつけてやった。 話すのは常に片方だけのようだった。 もう一方は考える役目で、話さなくても二人は意識を共有できてるのかと思ったよ。 人事部のおねえさん達の一人「シンパシー」が、彼らを連れてきて、「見当つかず」のオフィスへと引っ張って来たんだ。 15分後には彼ら全員が、俺のキュービクル(訳註:パーティションで区切られたデスクスペース) を揺らしにやってきた。 彼らに合流を要請され、会議室に集まったわけだ。 そこで、「見当つかず」は何事が起こってるのか説明した。 最高機密の部署から、確実にラップトップが無くなっていた。 転売目的で盗まれたようで、しかもその疑念は俺達に向けられていた。 もっとはっきり言うなら Boris にだ。 Boris 本人に聞く前に、やつのチームリーダーである俺に伺いを立てたってわけだ。

「見当つかず」が俺に以上のことを説明した後、「シンパシー」がまったく同じことを繰り返した、ただし人事部の観点から:名を伏せたとある政府の機関から連絡を受けたもので、彼らがほんとうにその機関から来ていることは確認しました、それからナントカカントカ。。。 そして、エージェントその1がまったく同じ内容を俺に繰り返した。 ただし、より短く、簡潔にだ。 彼は、ホラー映画で首の後ろの毛が逆立つような不気味な音楽がかかったときみたいな話し方をしたので、こいつはマトリックスを 1000回は繰り返し見ては、エージェントスミスの動きやイントネーションを全部覚えて、今回こそはひょっとしてエージェントスミスが勝つんじゃないかと祈ってるんじゃないかと思ったぜ。 それから俺達全員は行進して Boris のところへ行き、やつを会議室に連行した。 なんかの理由で違う会議室にしたんだ。 そしてそこで俺は、エージェントその1とエージェントその2 が、これを既に 3回繰り返してるんだということに気づいた。 最初は「シンパシー」、それから「見当つかず」、そして俺、だ。 そして今、別の会議室に来て、「見当つかず」がBorisに何があったか話し、「シンパシー」が Boris に何があったか話し、エージェントその1がBorisに何があったか話し、全員が俺を見て、明らかに俺が、Boris に何があったか話すことを期待してた。 カフカもこの同じシーンを体験したことがあるに違いない。絶対にだ。 だから俺は、Boris のやつに、エージェントその1、エージェントその2 とお話をしたらどうだい、と言った。 Boris が家に帰る前にまた会おう、と。

そこで初めて、エージェントその2 が何かするのを見たんだ。 やつは小さなメモ帳を取り出し、なにごとかを書きつけ、それを片付けた。 なんでかわからないが、部屋中の誰もが (たぶんエージェントその1は違うな。なぜかというのは説明しづらいけど) その動作によって催眠術にかかってしまった。 エージェントその2 の手はポケットへと動き、部屋の静寂は突然にうるさくなった。 俺達全員が、エージェントその2 がメモ帳を取り出す動作に目が釘付けになり、ペンの先で彼が書くものがなんであれそれを見逃すまいとした。 その場にいたら、エージェントその2 がメモを片付ける動作を追おうとして全員の頭がわずかに傾いてたのを観察できたと思うよ。 突然、俺達全員がそういえばすごく忙しいんだった、メール受けにはすぐに見ないといけない緊急の用事が山積みで、 私はここを出て行っても構わないでしょうね、と申し出た。 もちろん、Boris はエージェントその1とエージェントその2 による「尋問」のために残して。

俺は自分のキュービクルに戻り、急いで考えなきゃいけなかった。 俺達は全員、Boris の尋問の詳細は完全に秘密にしておくようにと言われた。 だけど少なくとも「大口」の奴が俺をあれこれと詮索するだろうということはわかってた。 まさにそのとき、奴が「いったい何があったんだい」と後ろから言ってくるのを聞いたんだ。 だから俺は奴に言ってやった。 これはまだ公表されてない事柄に関する秘密の調査で、去年から開発部に在籍してたけどそこから他に移った奴みんなが、尋問されようとしてるんだ。 もちろんそれは、俺、Boris と Weevil を指していた。 「それ」が鍵だったんだな。 たぶん、俺の人生で最大のひらめきだな。 30分もしないうちに、Weevil が俺のデスクに来て、何が起こってるのか教えろと言ってきた。 だから奴に言ってやったさ。 彼らはすでに俺を尋問済みで、俺は彼らが何を尋ねたか、言っちゃいけないことになってる。 それから声をひそめて、奴に教えてやった。 「だけど、彼らは俺がどう答えたかを言っちゃいけないとは言わなかった。 俺が答えたのは、『ゴールデンゲート』なんてプロジェクトに関わったことはないですよ、『ゴールデンゲート』プロジェクト、なんてもの自体、聞いたことがないんですから」

10月22日
エージェントその1 とエージェントその2 が尋問した後、その日は Boris を再び見かけることはなかった。 なぜなら、彼らは Boris の家に直行し、ラップトップを押収したからだ。 Boris は詳細を話すことを禁じられていた。 だけど、来週にまた尋問があることは教えてくれた。 Weevil は、彼らが俺と Boris だけ尋問して、 奴を尋問していないことを非常に気にしてるようだった。 俺は奴に、彼らは一人づつ可能性を潰してるんだよ、と言ってやった。

10月29日
さて、Boris が中古のラップトップを持ち出したらしいのは確かだ。 だけどそのことにはもう何の嫌疑もかけられてなかった。 一方、Weevil はエージェントその1 とエージェントその2 から、『ゴールデンゲート』とかいうプロジェクトのことで 尋問を受けているようだった。 どうも、奴は Boris の 2度目の尋問のときに、自分からエージェントその1 のところに言って、 彼は『ゴールデンゲート』プロジェクトのことなんて何も知らないんだ、とかほのめかしたようだ。 世の中には、黙ってるべきタイミング、というのを理解してない人がいるもんだなぁ、と思ったね。

またな

ジャバ・ザ・ハット


インタビュー: Bela Ban, JBossCache

今月は効率の良いレプリケートキャッシュである JBossCache のプロジェクトリーダー Bela Ban にインタビューしました。

JPT: 自己紹介をお願いします

私は JGroups (www.jgroups.org) と JBossCache (www.jboss.org) のリーダーです。 JGroup は Java による信頼性の高いマルチキャストのツールキットで、JBoss Clustering と JBossCache の基礎となるものです。 私はスイス生まれで、チューリッヒ大学で博士号を修めました。 チューリッヒの IBM の研究所で4年働いた後アメリカへ渡ってコーネル大学でポストドクターをやり、その後 2003年まで富士通ネットワークコミュニケーションズで働きました。 JBoss Group には2003年に加わりました。

JPT: あなたがたは JBossCache をリリースされたばかりですが、この製品について少し説明してもらえますか?

JBossCache はレプリケートされた木構造のトランザクショナルキャッシュで、トランザクションに基づいてプロセスの境界を越えてレプリケートできます。 あるツリーに要素を加えたら、その要素はクラスタ内のすべてのツリーに現れます。 キャッシュはローカルなものにすることも、レプリケートさせることもできます。 レプリケートさせる場合、非同期と同期とを選べます。 前者の場合は単純に変更点をバス上に流して即座にリターンし、バックグラウンドでレプリケートします。 後者の場合、クラスタ内のすべてのツリーが更新し終わるまで呼び出しをブロックします。 JBossCache はトランザクションに従うように使えます。 つまり、トランザクション処理を行えば、JBossCache はすべての変更をまとめておいて、トランザクションが終了した時点でのみレプリケートするのです。 もちろん、トランザクションをロールバックすればレプリケートしません。 要約すれば、JBossCache には主要な3つのモードがあります:

  1. レプリケートを全く行わない純粋なローカルキャッシュ
  2. 非同期なレプリケートを行うキャッシュ。あなたはツリーを更新するプライマリサーバを持ち、その更新内容はすべてのバックアップサーバに定期的あるいは即座にレプリケートされます。 レプリケートは常にバックグラウンドで行われます。 (プライマリサーバに変更を加える呼び出しをブロックしません)
  3. 同期レプリケートを行うキャッシュ。この場合はクラスタ内のすべてのツリーで 2フェイズコミットを実施してツリー間の一貫性が確実に保たれるようにしています。 このシナリオは、呼び出しから戻った後に変更点がクラスタ内のすべてのツリーに確実に反映される保証が必要な時に使われます。 もちろんこの追加の信頼性を得るにはパフォーマンス面での代償を支払わなければなりません。

JPT: キャッシュ製品を開発しようとするきっかけになったのは何ですか?

Marc のブルーペーパーの中で、スピードアップのためのキャッシュの必要性が説かれています。 主に使用される場面はクラスタ内のエンティティビーンへのアクセスです。 今のところ、クラスタ内のエンティティビーンにアクセスする時にはコミットオプション B か C を使わなければなりません。 このことが意味するのは、キャッシュを持っていてもトランザクションの終わりにはエンティティビーンをキャッシュから削除しなければならないということです。 キャッシュの目的に反しています。 そこで私達がしたいのは、トランザクショナルなレプリケートされたキャッシュを使って実際にエンティティビーンをメモリ上に保持することです。 これによりパフォーマンスが大きく改善されます (特に、読み出しの多いアプリケーションで)。 書き込みはまとめられてトランザクション終了時に全てのキャッシュにコピーされます。 そしてもちろんデータベースにも納められて永久化されます。 今は Synchronization インタフェースを使ってトランザクションをコミットするタイミングをトランザクションマネージャが通知するようにしています。 将来的には JBossCache を JCA ResourceAdapter にして分散トランザクションもサポートできるようにしたいと考えています。 また、私達はキャッシュの別の使い途も考えています:

一般的に、JBoss の周りには様々な形の多くのキャッシュが存在します。 JBossCache はそれらを統合して一つのキャッシュにしようとしています。 JBossCache は中心に有り、そこに加えられた改良からすべてのサブシステムは恩恵を受けます。 JBossCache は異なるモードで動作するように設定できるので、これはあくまでも JBossCache の能力の一つに過ぎません。

JPT: 元々はこの製品でどのような問題を解決しようとしていたのですか?

上の回答の通りです。過去も現在も主な問題はクラスタ内のエンティティビーンのキャッシュです。 しかしながら、私の考えでは JBossCache は単体でも有用なプログラムであって、JBoss コンテナの外に出してスタンドアローンで使うこともできます。

JPT: Marc [Fleury] は、このキャッシュは細粒度のオブジェクトに対して良いパフォーマンスを提供する最初の分散キャッシュソリューションだと主張しています。この主張に対するコメントをお願いできますか?

そこがゴールですが、私達はまだそこまで到達していません。 少し説明させてください。JBossCache には2つのバージョンが有ります: TreeCache と TreeCacheAop です。 TreeCache はここまでお話して来たものです。 TreeCacheAop は TreeCache のサブクラスで、オブジェクトの状態がいつ変わったかを知るためのクラスコードが組み込まれています。 このため TreeCacheAop 内のオブジェクトの変化を追跡でき、トランザクション終了時の変更点だけをレプリケートできます。 巨大なオブジェクトを扱っていてそのオブジェクト内のほんの数バイトだけが変更されるような場合に、これまでならばオブジェクト全体をシリアライズして送信しなければならず、シリアライズのために帯域と CPU サイクルが無駄になっていました。 TreeCacheAop の場合はこのオブジェクトの変更点を追跡できるので、その変更点だけをレプリケートします。 その結果、良好なパフォーマンスがもたらされます。 それは AOP が高速だからという訳ではなく (実際のところ、フィールドのインターセプションは速度を低下させます)、シリアライズと不必要なネットワークトラッフィックとを減らせるからなのです。

Ben Wang (カリフォルニア Cupertino 出身)は TreeCacheAop の部分を担当しています。 JBossCache にとって非常に大切な部分なので、ここで彼の名を挙げておきたいと思います。

JPT: どんなプロジェクトにおいても、私達はいつもどの辺がパフォーマンスのボトルネックになりそうかということを気にかけています。 あなたはどういった所を気にかけますか? また、実際にそれらがボトルネックになったことはありますか?

当り前のことですが、2フェーズコミットは常にコストのかかるものです。 別のボトルネックとしては、クラスタ内の異なるツリーに有る同じオブジェクトにアクセスする時に出会うかもしれないデッドロックです。 私達は、ロックの獲得にタイムアウトを設け、同じオブジェクトに同時にアクセスした 2つのトランザクションのうち片方はロールバックさせ、もう片方を成功させることによりこの問題を解決しています。 ただ、最終的には、分散環境でのデッドロックを検出するメカニズムを提供するスキームを作りたいと考えています。 そんなに簡単なことではありませんが。

JPT: 予想外のボトルネックに遭遇したことがあれば教えてください

予想外のボトルネックを見つけたことは全くありません。 かつて、私達のユニットテストのうちの一つがタイムアウトが原因で失敗したことがありました。 それで分かったことは、レプリケートされたツリーに 500箇所もの変更が加えられていて、そのすべての変更が一つのトランザクションにラップされてコミットされたということでした。 当然このために 500回の 2フェーズコミットが実行され、ダウンを引き起こしたのです。 これは実際のところは TreeCache の問題ではなく、その使い方の問題でした。

JPT: パフォーマンステストを行うために HP のラボへ行く予定が あるそうですね。興味深い選択です。少しその内容を教えていただけますか?

HP Professional Services は、彼らの顧客の多くが JBoss を使うのを目にしており、そのため、JBoss に関するサポートを提供できるようになりたいと考えています。 彼らはまた、パフォーマンスの問題を JBossGroup に戻す前に自分たちの手で解決したいと考えています。 そこで彼らは、パフォーマンスの実験設備を我々に使うよう申し出てくれました。 まずは JGroups と JBossCache とをテストするつもりですが、JBoss Clustering のテストにも興味はあります。

JPT: HP ではどんなベンチマークを行う計画ですか?どういった点を調べるつもりですか?

JBossCache について: 4ノードのクラスタを用意してそれぞれの上でテストドライバを実行する予定です。 各テストドライバは多数の変更をキャッシュに加えますが、テスト終了の時点で 4 ノードすべてが同じ状態になっていなければなりません。 このテストで JBossCache の信頼性と正確性とが調べられます。 それからパフォーマンスのボトルネックも。 JGroups について: メッセージの流量を1秒間あたり数百から1秒間あたり数千に増やすつもりです。

より大きなクラスタのテストもするつもりです: おそらく 20 台くらいの物理マシンで。 また以下のようなテストも予定しています:

JPT: もしもあなたに一つだけ Java に変更を加える権限があるとしたら、その変更はどのようなものになりますか?

私は Java のおかげでとても幸せですし、SUN は良い仕事をしたと思います。 細かな所で2点挙げると:

貴重なお時間をありがとうございました。

(インタビュー終わり).


今月の質問

私の使っているプロファイラは J2EE アプリケーションにとても大きなオーバヘッドを掛けてしまいます。代わりに使えるものは有りますか?

大きなオーバヘッド無しに適切な情報を取れるツールを見つけるまでいろいろなツールをいろいろな設定で試してみるしかない、ということはご自分でもお気付きのことだろうと思います。 GC の情報を取るには普通 verbosegc オプションが使えます。 また、先月の「今月の質問」(日本語版)で Xprof について説明したように、Xprof プロファイラを使ってほとんど無料で情報を得られます(もちろん HotSpot を使っているとして)。 しかし、もしも常に高負荷で運用中のサーバのプロファイルを取りたければ、オーバヘッドが非常に小さなものを使わなければなりません。 もしかしたら J2EE モニタが役に立つかも知れません。 http://www.javaperformancetuning.com/resources.shtml#ProfilingToolsNotFree の始めの方にリストされています。そこには別の種類のツールもリストされています。 http://www.javaperformancetuning.com/resources.shtml#ProfilingToolsFree には無料のものがリストされています。

これらツールの中にはたいていあなたの役に立つ計測結果を与えてくれるものが有りますが、もしそうでない場合には、自分自身でコードを調べる必要があります。 もしご予算が有れば良いパフォーマンスチューニングの専門家をご紹介できますが -;) そうでないなら、どこで何を使えば良いか見当を付けられるくらいにまでパフォーマンスチューニングの専門的な経験を自分で積まなければなりません。 残念ながら、この状況に対する魔法の弾丸は有りません。 この状況の元で情報を引き出してボトルネックを見つけだすという作業を通じて直感と経験がもたらされるのです。 もし私が一般的に通用する J2EE のボトルネックを確実に見つけだすやり方をいつか手にしたなら、それを本に書きます。

J2EE アプリケーションのプロファイリングはまだまだ進歩の途中です。 J2EE モニタのベンダはプロファイリングを簡単にしようとがんばっていますし、その製品により、パフォーマンスの問題点を見つけ出す作業は確実に加速されるでしょう。 そして J2EE のボトルネックのうち見つけだすのが非常に難しいようなものでも比較的簡単に発見できるようになっています。 それでも J2EE アプリケーションは、見つけ出すのに非常に骨の折れるボトルネックを抱えるほど複雑なものにしばしばなってしまうのです。

The JavaPerformanceTuning.com team


Tips(技法・裏技)

http://www.devx.com/Java/Article/18100
パフォーマンスを加速させる J2EE 設計戦略
(最終更新日 2003年12月、追記 2004年1月27日、著者 Lara D'Abreo, Publisher devX). Tips: http://java.sun.com/developer/JDCTechTips/2003/tt1208.html
SwingでのマルチスレッディングとThreadLocal変数
(最終更新 2003/12, 追記 2004/01/27, 著者John Zukowski, 出典Sun). Tips: http://www.devx.com/webdev/Article/17950
Apache JMeterによる負荷テスト
(最終更新 2003/12, 追記 2004/01/27, 著者 Kulvir Singh Bhogal, 出典DevX). Tips: http://www-106.ibm.com/developerworks/xml/library/x-tipstx2/
StAXでXMLドキュメントを部分的にパースするには
(最終更新 2003/12, 追記 2004/01/27, 著者 Berthold Daum, 出典 IBM). Tips: http://www-106.ibm.com/developerworks/apps/transform.wss?URL=/developerworks/websphere/library/bestpractices/httpsession_performance_serialization.xml&xslURL=/developerworks/websphere/xsl/bestpractice.xsl
効果的なシリアライゼーションでHttpSessionのパフォーマンスを改善する
(最終更新 2003/12, 追記 2004/01/27, 著者 Kyle Brown, Keys Botzum, 出典 IBM). Tips: http://www.developer.com/java/other/article.php/3286861
Java Sound パッケージについて、mu-law エンコーディングによるオーディオ圧縮
(最終更新日 2003年12月, 追記 2004年01月27日, 著者 Richard G. Baldwin, 出典 developer.com). Tips: http://www.informit.com/isapi/guide~java/seq_id~63/guide/content.asp
パフォーマンスチューニング
(最終更新 2003/12, 追記 2004/01/27, 著者 Steven Haines, 出典 informIT. Tips: http://www.onjava.com/pub/a/onjava/2003/04/02/multiple_submits.html
多重送信に対処する(最終更新 2003/4, 追記 2004/01/27, 著者 Al Saganich, 出典 OnJava). Tips:

Jack Shirazi


Last Updated: 2004-3-1
Transcopyright 2001-2004 JavaPerformanceTuning translation team. All Rights Reserved.
contributors: Tsuyoshi FUKUI, Akky AKIMOTO Hiroki, Yasunori Taniike, Nobuyuki Hirashima, Yoshie HAMANA, Yukio Andoh
Copyright © 2000-2004 Jack Shirazi. All Rights Reserved.
Original URL: http://www.JavaPerformanceTuning.com/newsletter038.shtml
URL: http://javanews.jp/javap/newsletter038.html
Japanese version maintained by Yukio Andoh - andoh@javanews.jp