なによりもまず、もし J2EE アプリケーションパフォーマンス管理 (APM) ソリューションをお持ちで、私が今度書くレビューに取り上げてほしいという方がいたら、できるだけ早く当方まで ご連絡ください。 いくつかの記事にわたって、パフォーマンス管理の全分野を見ていく予定ですので、ぜひこの機会をお見のがしなく。
次に、私に直に会ってみたい、あるいは私の Java Performance Tuning 本を無料でゲットしたい方は、 アプリケーションパフォーマンスのページ をみてください。 来月ロンドンとレディング（英）で行う私のトークに参加登録していただけます。 参加していただける方とお会いするのがとても楽しみです。
また、私たちは公開の Java パフォーマンスチューニング教育講座の開始を発表できることを喜ばしく思います。 私たちの最初の講座は トロント、 ストックホルム、 そして フランクフルト で開催予定です。 これらの講座に関心のある方は 当方までご連絡ください。
今号のニュースレターでは、おなじみの記事、ニュースその他盛りだくさんでお送りします。 ニュースではまたしても Java 対 C++ のベンチマークが多くの議論を呼んでいますが、今回は Java の方が有利な結果を出しており、C++ ユーザーのほうが必死になって不公平だと叫んでいる状態です。 このようなベンチマークは根本的に無意味だ、というのが私たち JavaPerformanceTuning.com の見解です。 あなたが何をやりたいにしても、Java は十分に速いうえに、他の著名な言語よりもはるかに生産性が高いのです。
そして記事の方ですが、JavaWorld が完全に復帰しました。 彼らは先月リストにあげたような良い記事を生み出し、そして今月はさらに良い記事がリストにあがっています。 加えて、いつものセクションも健在です。 Kirk のまとめ ではいくつかの興味深いディスカッションを扱っています。 Javva The Hutt も最新の日記とともに戻ってきました。JavaOne への出張旅行をもぎとれなかった自分の無能さを嘆いています。 そして 今月の質問 では、JVM の監視をするときにどのメモリを計測すればいいのかを尋ねます。
今月の記事は DevStream社の JView J2EE パフォーマンス監視ツール の機能についてレポートします。 その他、漫画の新作 と 多数の新規パフォーマンスtips を簡潔に抽出しています。
Java パフォーマンスチューニング関連ニュース
またしても私たちは Java と C++ の速度を比べるという素朴な試みに関わってしまったようです。 率直に言って、この手の比較に意義があるとは思えないため、情報源について言及するのはやめておきます。 ［編注：今月の ニュースセクション 参照 ］ まず、いったい何を比較しているというんでしょうか？ 二つの別の言語によって書かれた、あるタスクの計算を行うためのコストだとしたら、どのタスクを選ぶべきでしょうか？ 自分の過去の記事で、私はベンチマークは具体的な質問に対する答えを出すように作られるべきだと主張しました。 「どの言語がより速いか」というのは具体的な質問ではありません。 現在の技術の状況では、Java（JIT と HotSpot 実行時プロファイラを含む）は静的な C++ コンパイラが出力するコードに比べて大幅に最適化が進んだネイティブコードを動的に生成できることは誰でも知っています。 さきほどの問いに対して答える側にとって、これは無限の問題の入り口にすぎないのです。
今日、コンピュータの計算能力は、現在私たちが解決しようとしているビジネス上の問題のほとんどを解決するのに十分なほど増加しています。 これは、答えが求められていてもこの惑星上には十分な計算能力がない、という多数の問題など存在しない、と言っているのではありません。 しかし一般的には、そのような問題はビジネスの興味の範疇にはありません。 これを考慮した上で、C++ がほんの少しだけ Java より速いとか、Java がほんの少しだけ C++ より速い、といったことに意味はあるのでしょうか？ 本当は「アプリケーションの開発、運用、保守に関わる総合的なコストはどれほどか」となるべきではないでしょうか？ 結局、これがほぼすべてのアプリケーションのライフサイクルにおけるボトルネックなのです。
Java Ranch からご紹介する最初の質問は、Vector の中身をイテレートする前に ArrayList に変換するための賢い方法を尋ねるものでした。 まずいくつかの前提となる情報から始めましょう。 質問の投稿者は、TopLink から Vector を得ていました。 TopLink は現在 Oracle が所有している O/R マッピングツールです。 ツール自体は Java 以前から存在しているため、Java にとっては最初期から存在する O/R マッピングツールの一つとなっています。 その古さの結果として、かつての Java バージョン 1.1 の名残が残っているというわけです。 このケースでは、確かに Vector は Java2 のコレクションフレームワークに改良されましたが、これはすでにレガシーに属するクラスです。 Vector は同期化されているため、使う側にとってはわずかながら性能悪化につながる、というのがレガシーである理由の一つです。 一方で、ArrayList は同期化されておらず、性能悪化を引き起こすことはありません。 問題は、その性能悪化はどの程度のものなのか、ArrayList に変換してから読み出すというコストに見合うものなのか、という点です。 どのようにその情報が使われるのかを知らなければ、残念ながらこの問いに答えることはできません。 今回のケースでは、回答は Vector が保持するオブジェクトの数と密接に関係するでしょう。 小さな Vector をわざわざ変換するだけの価値はないし、アプリケーションの性能にも何ら影響はないでしょう。 その上で、本当にその効果を知る唯一の方法は計測すること以外にありません。 またしても「推測するな、計測せよ！」のケースに私たちは巡り会ったというわけです。
"write once, run anywhere" の題目にはほころびが見え始めているようです。 OSX の JVM がベンチマークでは非常に遅く見える、という長いけれども興味深い議論から、最新の証拠が表れました。 「遅く見える」と書いたのは、Mac のハードウェアにはいくつか顕著な差異がある関係で、OSX に Sun の JVM のきれいな移植を行うことができないためです。 このハードウェア上の差異の結果、Apple は Sun の JVM に見られるような多くの最適化を組み込めずにいます。 これらの最適化は server 版の HotSpot も含んでいます。 その上で、デフォルトの設定では client HotSpot が使われることから、ユーザーは性能の違いに気づかないかも知れません。 どうやらゲームプログラマたちはハードウェアの差異のために Intel の Pentium テクノロジーより Apple の G4 の方がパフォーマンスが良いと気づいているようです が、G4 をサーバーとして使おうとしている人々には多少残念な話かも知れません。
ウェブサイト「the serverside」からは、どうやったらトランザクションプールを使って DB とのやりとりを減らすことができるのか、という興味深い議題を紹介しましょう。 質問文から、そのアプリケーションでは数時間で 15,000 のコネクションを受けることになっているとわかりました。 質問に対する回答を読み進めるうちに、おや、この程度のアクセスで、本当にこんな複雑な対策が必要なのだろうか、と私は思い始めました。 頭の中でちょっとした計算をしようとし始めたまさにそのとき、私に代わってその計算をしてくれた回答を読むことができました。
その分析では、数時間というのを3時間であると仮定しています。 仮定では、毎回のトランザクションでは20行のデータが挿入されるとします。 この見積もりは、それが、ユーザが入力したフォームを処理するアプリケーションだ、という情報から立てられました。 以上から、15,000 / (3時間 * 3600 秒)、つまり 1秒あたり 1.4トランザクション、という数字を導けます。 このトランザクションレートは、現在手に入るどの商用 RDB でも問題なく扱えそうなものですし、このトランザクション数を減らそうというのは早まった最適化のように思えます。
最後の投稿では、レガシーアプリケーションとのやりとりで限界に達しようとしている J2EE アプリケーションについての話でした。 その J2EE アプリケーションでは、時間に依存する情報を、可能な限り高速に pull/push することが求められていました。 そして、そのシステムに絡む様々な制約が列挙されました。 面白いことに、最初の回答者が、まず、質問者が、「可能な限り高速」という言葉の意味するところを定義するべきだ、と指摘しました。 「可能な限り高速」という条件は決して達成できません。 なぜなら、その定義するところは、技術の変化に従って変動するからです。 そのデータは時間に関連する、と定義されていました。 が、その意味するところは、そのデータは、ビジネスルールによって定義された「保存期間」を持たねばならない、ということでしかなかったのです。 このような情報が、性能要求を確定させる助けとなり、それによってエンジニアは合理的な目標を持って作業することができるのです。
回答はさらに、こういう質問になりました。アプリケーションの性能を制限している資源の制約は何ですか？ 元の投稿ではそれがどんな資源制約なのかの手がかりを提示していませんでしたが、彼らが試したいくつかの作業内容が書かれていました。 与えられたそれらの作業内容から、それらの試みのどれかが、与えられた目標を達成しそうかどうかを推測するのは非常に困難でした。
マーズローバー(火星探査機)がどうやって故障から復活したかを書いたこのすばらしい記事 は読んだかい？ この記事を読んでいると、性能問題を追跡しようとした時の事を思い出すよ。 今手に入るすべてのアプリケーション性能測定ツールを使ったとしても、性能問題の特定というのは時に非常に困難な作業だ。 彼らのように、最後は輪になって頭を寄せ合い、なんだかぼやっとした手がかりをきっかけについには正しい追跡の路を見つける、というわけさ。
3/10
仕事で溺れる。
問題というのはバス待ちみたいなもので、長いこと待たされたと思ったら、突然何台もまとめてやってくるんだ。
君らのほとんどは、そんなのはあたりまえのことでいまさら珍しくも無い、と言うだろうがね。
3/24
まだ水に浸かってる。
それらに加えて、個人的な、喜ぶべき、だけどもとても時間を喰う事柄で忙殺されている。
4/14
くそっ。君ら全員と、たとえ全員でなくても君らのうちほとんどのやつらと同じように、ジャックのエイプリルフールネタ (コマンドーパターン) でボロを出しちまった。
ジャックに「俺がバッドプラクティスだと思ってるものを、パターンだなんて強調すべきじゃないぜ」、なんていう抗議のメールを送ってしまった。
彼がエイプリルフールだよと返事してきたときは、ほんと恥ずかしかったなぁ。
読み直してみれば、明らかにそうだった。どうして最初読んだときに気づかなかったんだろう。
いまだに、あれはエイプリルフールの芸術だと思ってるよ。
よくよく読まないと信じてしまいそうなところがね。
あの有名な 「スイスでは今、スパゲッティの収穫期です」 ネタに引っかかったやつが煙に巻かれたやつのようにね。
もっとも、1957年には今ほどスパゲッティがありふれた食べ物じゃなかったとは思うが。
4/21
JavaOne には行けないことになった。
またしてもだ。
Weevil のやつも行けないけどな。
信じられるかい？
Boris がそれをせしめたのさ。
チームから一人だけ行けることになって、あらゆるインチキを企てたんだが、うまくいかなかった。
Boris と Brainshrii は俺の「簡単に結果が出る」クジのことを良く理解してて、別の中立なクジを使うべきだと主張したんだなこれが。
人事部には特定の誰かに行かせたいとか、ひいきしないといけないとかいう理由がないと見抜いたやつらは、
人事部の Sympathy(ハットのつけたあだ名) にその作業をさせた。
カップに小さな紙切れを入れて、十分手が届かない距離からそれを引かされたんだ。
じれったいことだ。
簡単に理解できる短くて公正なクジを Java で書いてやれたのに。
もちろん、クラスパスには俺様謹製の乱数生成器を含ませるんだけどな。
音声入力をスキャンして特定の高さの音で動作するようなプログラムを作るのが
どれぐらい複雑なことか知ってるかい？
まず音声入力をつなげて、サードパーティー製の音声認識変換ライブラリを使い、その特定の単語を話したものをスキャンし、システム全体をテストし、俺の合言葉にちゃんと反応するようにしたのさ。
そこまでやっておいて、それを使うことすらできなかったとはね！
夕方からの全作業がパァだ。
ここでは俺の才能は無駄遣いされている。
かといって、他にそれをありがたがってくれるところがあるかどうかは知らないけどな。
またな
プロファイラが示すメモリ使用量の値が freeMemory() によるものとも OS のモニタによるものとも違っています。どれが正しいのでしょう?
3種類のツールの違いによって、3種類の JVM メモリ使用量が得られます:
これら3種類のツールはそれぞれ違うものを計測しており、どれが何を計測しているのかを知ることは有益です。 OS のプロセスモニタツールが計測するプロセスのメモリ使用量とは、オブジェクトのヒープとその他のメモリスペース (プロセスの実行に必要なメモリスペース、スレッドの実行時スタック、スレッドごとのヒープ、JNI で使われるスペース、JNI のコード内で生成されたオブジェクトのスペース、ロードされたクラスが格納される PERM スペースのような JVM が直接使うスペースなど)とを合わせたものです。
Runtime freeMemory() メソッドは、オブジェクトヒープの大きさに関しては正確であるはずです。 しかし、この計測結果はプロセスの実行に必要なメモリスペースや JNI により確保されたスペースや JVM 内部のデータ構造 (コンパイルテーブルなど) のスペースの分を含んでいないかもしれません。 このメソッドがスレッドの実行時スタックやスレッド毎のヒープのスペースを含めるという保証も有りません。 また、PERM スペースが含まれるかどうかも分りません。 このメソッドがどんな値を返すべきかを規定する仕様が無いため、JVM が違えば測定するものも違う可能性が有ります。 Runtime.freeMemory() が報告する値は OS のプロセスモニタが計測するサイズよりも 小さくなるはずです。
プロファイラ込みで実行をすると、計測値に歪みが出てしまいます。 なぜならプロファイラ自体がヒープと実行時スペースとを必要とするからです (JVMPI ベースのプロファイラの場合)。 プロファイラが報告するのは Runtime.freeMemory() によるものとほぼ同じはずですが、プロファイラ自身が使用しているメモリスペースの分を除こうとするために食い違いが生じます。 長期にわたって実行を続ける場合やオブジェクト生成やガベージコレクションの統計を取る場合などにはプロファイラは非常に大きなメモリスペースを必要とすることが有ります。そういう場合には OS や Runtime.freeMemory() が示す値とプロファイラが報告する値とは大きく異なってしまいます。
プロファイラを使う場合、プロファイラの示す値はチューニングする箇所を決めるのに使いましょう。 プロファイラ使わない場合、Runtime.freeMemory() メソッドや -verboses:gc オプションをヒープサイズをモニタするために使いましょう。 OS のモニタはプロセスの大きさを監視するために使い、RAM の大きさにちゃんと納まっていることを確認しましょう。
The JavaPerformanceTuning.com team
http://www.hwcs.com/products/diagnosys/enews/20040519.asp
パフォーマンス戦略を発展させる
(最終更新日 2004年7月、追記 2004年6月30日、著者 Author H&W、出典 H&W). Tips:
http://www.stpmag.com/stp001.htm
高性能ソフトウェアの定義と構築
(最終更新日2004年3月、追記2004年6月30日、著者 Adam Neat、出典 STPmag). Tips:
http://www-106.ibm.com/developerworks/xml/library/x-trans1.html
[ 翻訳記事 http://www-6.ibm.com/jp/developerworks/xml/040903/j_x-trans1.html ]
XML の転送性能の改善 Part 1
(最終更新日 2004年6月、追記 2004年6月30日、著者 Dennis M. Sosnoski、出典 IBM). Tips:
http://www-106.ibm.com/developerworks/xml/library/x-trans2/index.html
[ 翻訳記事 http://www-6.ibm.com/jp/developerworks/xml/040910/j_x-trans2.html ]
XML の転送性能の改善 Part 2
(最終更新日 2004年6月、追記 2004年6月30日、著者 Dennis M. Sosnoski、出典 IBM). Tips:
http://www.devx.com/Java/Article/20891
JDBC コネクションプール
(最終更新日 2004年4月、追記 2004年6月30日、著者 Alexey Prohorenko and Alexander Prohorenko、出典 devX). Tips:
http://www.informit.com/articles/article.asp?p=174099
TCP のチューニングを理解する
(最終更新日 2004年5月、追記 2004年6月30日、著者 Deepak Kakadia、出典 Prentice Hall). Tips:
http://weblogs.java.net/pub/wlg/1393
メッセージドリブンビーンにおけるメッセージの確認応答と再送
(最終更新日 2004年6月、追記 2004年6月30日、著者 Simon Brown、出典 java.net). Tips:
http://www.onjava.com/pub/a/onjava/2004/03/31/clustering.html
Tomcat 5 におけるクラスタリングと負荷分散 Part 1
(最終更新日 2004年3月、追記 2004年6月30日、著者 Srini Penchikala、出典 OnJava). Tips:
http://www.javaworld.com/javaworld/jw-05-2004/jw-0517-optimization.html
J2EE アプリケーションの最適化
(最終更新日 2004年5月、追記 2004年6月30日、著者 Rahul Kuchhal、出典 JavaWorld). Tips:
http://www-106.ibm.com/developerworks/java/library/j-jtp02244.html
[ 翻訳記事 http://www-6.ibm.com/jp/developerworks/java/040416/j_j-jtp02244.html ]
Java メモリモデルの修正 Part 1
(最終更新日 2004年2月、追記 2004年6月30日、著者 Brian Goetz、出典 IBM). Tips:
http://www-106.ibm.com/developerworks/java/library/j-jtp03304/
[ 翻訳記事 http://www-6.ibm.com/jp/developerworks/java/040514/j_j-jtp03304.html ]
Java メモリモデルの修正 Part 2
(最終更新日 2004年2月、追記 2004年6月30日、著者 Brian Goetz、出典 IBM). Tips: