RebeLabsは，2015年3月に開始した開発生産性に関する調査の結果を，“Developer Productivity Report”として公開した。Javaの開発コミュニティを対象に，Javaのパフォーマンスと性能試験手法について調査したものだ。
調査結果を見ると，パフォーマンス上の問題が明らかになった場合に対処するのは，一般的には開発チームであることが分かる。さらに，40%以上がコードのプロファイルを問題発生した時点で行っていると回答していることから，パフォーマンス問題に対するプロファイルやテストが対処療法的に実施されていることも明らかだ。
1,562件の回答中，ソフトウェア開発者は65%，27%がアーキテクト，次いでチームリーダ，プロジェクトマネージャの順で，専門のパフォーマンスエンジニアは少数(1.5%)だった。アプリケーションの大部分(70%)はWebアプリケーションで，画面数の平均は118である。
調査から，多くのJava開発者が，アプリケーションのプロファイリングにVisualVMを使用していることが分かった。VisualVMはJDKに同梱され，簡単なプロファイリング機能を備えている。 また，回答者のほぼ半数が，プロファイリングに２つ以上のツールを使用すると回答している。
パフォーマンス問題を発見する最も一般的なソースはフィードバック(31%)で，次いでパフォーマンス監視ツール(25%)，システム障害やクラッシュが20%である。この結果からは，デプロイ前のコードテストやパフォーマンス問題の検出がほとんど行われていないことが分かる。
パフォーマンス問題の根本原因として最も多いのは，性能の悪いデータベースクエリ(55%)で，それに近いのが非効率なアプリケーションコード(51%)である。HTTPセッションの増加が問題と答えたのは回答者のごく一部(8%)だった。
エンドユーザから高い満足を得られたプロジェクトには，小規模チームによる開発，効率的で積極的なパフォーマンステストの早期実施といった特徴があると，今回のレポートは結論付けている。このようなプロジェクトは，問題に対する判断が早く，40%が毎日あるいは週単位でプロファイルを実施している。
これらの数字が現実の経験とどの程度一致しているか確認するためInfoQは，パフォーマンスの専門家としても広く知られる，JClarityのCTOのKirk Pepperdine氏に話を聞いた。
InfoQ:&nsp;RebelLabsが先日発表したJavaのパフォーマンスに関する開発生産性のレポートについて，どう思われますか？
全体的に見て，興味深いものだと思います。いくつかのベストプラクティスが指摘されていることは間違いありませんが，そう見えるものの内のいくつかは，“民間伝承チューニング”とでも呼びたいようなものです。つまりチューニングのプラクティスが，現在のデータに基づいた状況的事実よりも，過去の経験に基づいているのです。これはある種の先入観として，結論を間違った方向に導く可能性があります。今回のレポートは，今日のアプリケーションが直面している一般的問題のいくつかが完全に見落されている，という点で，私たちの持つたくさんの先入観を反映しているように思えます。これは調査を行った側の責任ではありません。先入観によって見えていないものは報告されない，という単純な理由によるものです。その意味でこのレポートは，現在のパフォーマンスチューニングの“最先端技術”を見事に表している，と言ってよいでしょう。ここではその問題から一歩下がって，もっと広いコンテキストで考えてみたいと思います。
私の経験では，開発者がパフォーマンスチューニングについて語る時には，作業をより早く終わらせるためのアルゴリズム的な，あるいは，言わゆる巧妙な方法を見つけ出すというような，診断的な面にとらわれがちです。診断プロセスに関する議論は，チューニングのクリエイティブな面とは切り離した方がよいと思います。診断は，何が悪いのかを知る手段に過ぎないからです。問題が分かったら，その次には，それを解決するよい手段を考えることになります。言い換えれば，アプリケーションが実行時の条件により適合するような対応をいくつも実行する以前に，現在の条件下でパフォーマンスが不十分な理由を理解しておく必要がある，ということです。
私が気付いたのは，診断作業や巧妙なアルゴリズム開発がほぼ同じ知識ベースから導き出されたものでありながら，まったく別のスキルセットに依存している，という点です。私の知る限り，この両方のスキルセットを兼ね備えた人はほとんどいません。 ワークショップの参加者にはいつも最初に聞いているのですが，彼らの95%は，比較的単純な問題の解決に取り組む前に，まず全員が“私はそうではない”と答えるのです。不思議なことに，開発者として優秀である人ほど，診断的なスキルが不足している傾向があります。優秀な開発者には優れた診断スキルは習得できないとは言いませんが，あまり積極的ではないのでしょうね。実際に指示を与えてみると，彼らの90%は，非常に難しい問題を判断することができたからです。
レポートで目に付いた結果のひとつは，開発者は問題を分析する時に，直接的でない，あるいは独断的な選択をする傾向があるという点です。その結果が不統一なものになることは，目の不自由な人が象について調べるような状況を思い浮かべれば，理解して頂けると思います。
レポートで最大の問題として挙げられていたのは，DBクエリのパフォーマンスでした。実際には，データベースのパフォーマンスが不足することはめったにありません。ほとんどの場合，問題はDBではなく，アプリケーションがDBとインタラクションする方法にあります。私が最近経験した“データベースが遅い”という問題でも，DBの応答時間は2ミリ秒程度であることが分かったのですが，アプリケーションがクライアント操作毎に20,000回のコールを発行していました。私が依頼されたのは，100万回のコール中の1コールが，完了までに数秒かかっている理由を見つけることだったのですが，ちょっと計算すれば，100万回に1回の発生事象ならば50回のクライアント操作に1回であることが分かります。ですからそれは本当の問題ではありません。しかし，アプリケーションに必要なデータベースコールはたった３つだったのです。3つのコールで100万回に1回ということは，333,333回のクライアント操作毎に1回，遅いクエリがあることになります。20,000コールの遅延が40秒ですから，3回のコールならば10ミリ秒以内で完了するはずです。同じようなテーマのさまざまなバリエーションを数多く見てきたので，データベースの応答が遅い問題には，いつも同じ答を返すようにしています – “民間伝承チューニング”をしていませんか？
パフォーマンスチューニングは黒魔術ではありません。従うべきプロセスがあります。このプロセスについては，“The (not so) Dark Art of Performance Tuning”，“Performance Tuning with Poor Tools and Cheap Drink”という講演でも取り上げていますが，その方法論の基本はマシンに耳を傾けることです。どこが悪いのか教えてくれるでしょう。あとはその情報を，アプリケーションの動作にマップすればよいのです。このステップに従えば，パフォーマンスボトルネックを簡単に分離することができるはずです。
InfoQ:&nsp;ほとんどの回答者が，プロファイリングにVisualVMを使用していると答えていますが， 一般論として，これは正しい選択だと思われますか？
先程の答から，私がツールにはまったく固執しないことが分かって頂けたと思います。このことは，さまざまな場所で反映されています。実を言うと私は以前，NetBeansドリームチームのメンバでした。しかもNetBeansそのものよりも，VisualVM関連の開発を担当していたのです。その頃からかなり時間は経ちましたが，VisualVMは取付きやすく，拡張や変更もとても簡単です。パフォーマンスツールを自作するためのコンテナにはちょうどよいので，人気があっても不思議ではありません。私のワークショップに参加した人のほとんどが，何らかのVisualVM使用経験を持っています。余談ですが，NetBeanのプロファイラであるjFluidもVisualVMのプロファイラを使っていますから，約55%がVisualVMを使っていることになります。JMCがもっと一般的になって，多くの人たちがその存在に気付いてほしいと思います。プラグインのサポートや，ライセンス問題が解決することを期待したいですね。
InfoQ:&nsp;チームに対して，開発あるいはQAプロセスの一部としてパフォーマンステストを実施するように勧めるには，どうすればよいのでしょう？
これは大きな問題ですね。パフォーマンステストを，“買い主危険負担”のアクティビティとして説明するのが一番よいでしょう。このアクティビティにどの程度まで深く関わりたいかは，組織にとってパフォーマンスがどの程度重要であるかによります。もしバッチジョブが２時間や１時間ではなく３時間掛かったら，どんな問題があるのか？これはビジネスケースでのみ答えられる質問です。パフォーマンスが重要ならば，どの程度重要なのかを聞かなくてはなりません。開発ライフサイクル全体の内部にテストを組み込む必要があるのか，そこから判断しなくてはならないからです。実際には，さまざまなスケールで実行するベンチマークをセットアップしている，ということの認識も必要です。ほとんどの組織は，価値ある結果を得るためのベンチマークを実行するコストがどの程度なのか，単に理解できていないだけなのです。このことを多くの人たちに話すのですが，他に隠れたコストがあるのではないかと言って，なかなか信じてくれません。
どのようなベンチマークでも，時間的コストが最も必要なのは検証作業です。ベンチマークを評価しなければ本当の意味は分かりませんし，そこに現れた問題が事実なのか，あるいは見せかけなのかを理解することは困難です。これについても，このレポートのデータから，利益という面で判断することができます。レポートに見られるパフォーマンスチューニングは，ほとんどがかなり控えめなものです。もちろん，アプリケーションの性能要件がそれで満たされているのならば，それで十分であったのかも知れません。検証には多くの実験を重ねて，その結果を分析することが必要です。自分が考えていることが正確にテストできているという確証も必要です。そうでなければ，テストすべきものがテストできるように，何らかの調整が必要になります。このようなテストでは，セットアップと検証に数週間を要することも珍しくありません。 それでも重要なのです。
私が以前作業していたチームでは，テストは正しく行われていたのですが，検証が適切ではありませんでした。その製品は，パフォーマンス要件を満たさなかったため，リリースが３ヶ月遅れることになりました。動作環境には明確な問題が見られなかったので，チームは“不明確な問題”であるという結論を出しました。当然ながら，結果は何も変わりません。最終的な検証段階に入って，動作環境上の問題が発見されました。それを修正したところ，アプリケーションは十分な速度になったのです。これは普遍的なテーマで，私も何度となく出会いました。
InfoQ:&nsp;調査結果からは，ロードテストが多くの場合，後付けで実行されていることが分かります。ロードテストを計画的に実行するには，どのようなツールやプラクティスがよいと思われますか？
そうですね，残念なことに，一般的なワークフローにはロードテストは含まれていません。 継続的デプロイメントに便乗する形で実行しようとしている人もいますが，それもひとつの方法でしょう。１日掛かりでビルドしてロードテストする，それはいいのですが，落とし穴があります。 ロードテストの設定が適当でないと，追跡しているのが実はプラットフォームの問題であったり，あるいは問題を検出するのに十分な負荷をかけられていない場合があるのです。ツールの質問に戻りますが，アプリケーションに負荷をかけるツールは世の中にたくさんあります。商用ツールは使いやすいのですが，非常に高価なものが多い傾向があります。Webが使える環境であれば，利用可能なサービスもあります。概ね期待通りには動作しますが，あまり多くは期待しない方がよいでしょう。
私はApache JMeterをよく使っています。ツールとして欠陥がない訳ではありませんが，CO(Coordinated Omission)に関するアイデアがたくさんあります。Gil Teneはこれらを，JMeterを使用したアプリケーションのロードテストの経験から得たと言っています。JMeterの問題のいくつかには回避策があります。COに悩むツールJMeterだけではありません。実際，私の知っているどのツールでもCOでは苦労します。要はCOを意識する限り，COには何らかの対処をしなければならない，ということです。私自身が最悪だったのは，独自のロードテストツールを開発しようとしていたチームの時です。Apache JmeterやGrinder，Gatling，他の同種のツールは，一般的にファイア・アンド・レスポンス形式のスレッドモデルで動作します。ですから通信が完全に非同期でない限り，自分自身のロードインジェクタを展開しないようにしています。ロードインジェクタの記述は簡単ですが，詳細な部分は本当に大変なのです。実際に私たちがApache JMeterで体験した基本的な問題は，プログラムを完全に作り直さない限り解決しない類いのものなので，回避策で対処することにしています。
InfoQ:&nsp;クラウド導入に固有のパフォーマンス問題についてはどうでしょう？どうやって特定して修正すればよいのでしょうか？
クラウドでもベアメタル展開でも，それほど大きな違いはありませんが，ない訳ではありません。VMはVMであって，本当のハードウェアではないからです。自分が所持している以上のハードウェアに，自分自身を仮想化することはできません。ですから，周りの人たちが何をしようとしているのか，知っておかなくてはならない場合もあります。CPUの未使用時間監視の重要性を軽視するつもりはありませんが，CPUの可用性が問題になることは多くありません。私が以前，クラウド導入中のクライアントと仕事をした時，彼らのアプリケーション自体は何も問題はなかったのですが，一緒に動作しているのがOracle DBで，そのマシンにはネットワークカードが１枚だけだった，ということもありました。何が問題だったのか，お分かりですよね？
InfoQ:&nsp;最後に，パフォーマンスに関するアドバイスをお願いできますか？
パフォーマンス目標が満足できていなければ，ハードウェアの声を聞いてください。理由が分かるはずです。あとはその理由を，アプリケーションにマップすればよいのです。