トラブルシューティング アプリケーションパフォーマンス

developerWorksの記事で、アプリケーションパフォーマンスの話が書いてありました。このトピックも、何回も繰り返されるトピックで、永遠のテーマでもあるのでしょう。
http://www-128.ibm.com/developerworks/lotus/library/app-troubleshooting1/
いったい、どのようなことが書いてあるか気になるので、少し読んでみました。

まず、最初のパフォーマンストラブル解決のアプローチとしては、次の３つがあるようです。

1. 問題は、どこにあるのか
   Dominoアプリ、サーバー、ネットワーク、どこに問題があるかを特定させます。１つのアプリだけなのかどうか。また、他のサーバーではどうか。ユーザーのロケーションによって違うか。時間帯は。問題発生のユーザーのクライアントに特徴はあるか。クライアントのOSは。
   
2. 問題は、どこにあるのか
   現象が発生するアプリケーションの範囲や、ユーザー操作をしぼります。DBを開くときか、ビューを開くときか、ビューのスクロールか、特定のビューか、全てのビューか、文書の閲覧/保存時か、どんなアクションのときか、特定ボタンを押したときか
3. 変更はあったか
   以前からそうだったか。ユーザーやデータが増えたときからか。新機能追加のタイミングからか。ソフトウェア/ハードウェアのアップデートからか。

これは、確かに、書いてある通りだと思います。少しでも経験があれば、誰もがこのアプローチをとると思います。

次に、こうして集めた情報をもとに、悪いと考えられる場所を特定し、その部分をアプリケーションの観点から見直します。これも、当然といえるでしょう。

次はデータの収集です。データが集まれば真の問題点が明確になってきます。
収集すべき箇所は、問題にょって違いますが、通常は notes.ini などをベースにした、詳細なログの収集を行います。例えばビューに問題がありそうなら、log_update=1を使います。

最後に、集めたデータを解析して、問題点の箇所がそこにあったかどうかを判別します。
基本的には、このサイクルに従って、問題点を見極め、そこのチューニング、改善をするということですが、これもまあ、その通りだと思います。

実際のトラブルシューティングでは、アプリのパフォーマンス問題は、経験的に以下の3種類に分類されることが多いそうです。

• フォームのデザイン
• エージェント
• ビュー索引

私の数少ない経験からいっても、これらはあてはまると思います。

ここからは、ここで紹介されている、トラブルシューティングの実例です。
この例では、日中の多くの間、アプリが遅いという問題が発生していたそうです。話を聞いてみると、ビューの操作が遅いということで、ビュー索引のところから問題追求がはじまりました。
log_update =1を使ってみたところ、１つのビューの更新サイクルが30分以上だったようです。DominoのUpdateタスクはデフォルトで 15分単位で動きます。文書更新が全くない場合は動かないため、30分以上間隔があくこともありますが、ビュー索引の更新に非常に時間がかかって、15分サイクルが遅延し ているという可能性もあります。今回の、トラブル対応チームは、まずここに目をつけたようです。
15分サイクルの遅延において、DBやビューの数が多すぎて更新が本当に間に合わない、というこ ともありますので、特定のビューが悪いのかを見極める必要があります。今回はlog_update=2を使って個々のビューのログ状況を確認することにしま した。このケースでは、少数のビューの索引更新に非常に時間がかかっていることが判明し、ビューはアクセス時に「再作成」されるように記述されていること がわかりました（つまり選択式、列式に@Today/@Nowが入っていたのです）。
こうして、ビューのロジックを変更し、問題は無事におさまりました。問題判明に要したのは5日ほどで、あとは10-20日でロジック変更、テストをして解決したようです。

いかにも、というかんじで、、、ビューの@Todayが問題なら、もう少しすぐにわかってもよいのではないでしょうか、、、とも、思いますが、ともあれ、事例だそうです。

問題となるコードとしては、経験的に以下のことが多いそうです。

• 時間依存なビュー
  @Now/@Today などが選択式、列式に入ったものは、「再構築」されるので時間がかかります。(なお、Domino6のUpdateタスクは賢いこ とに、このビュー再構築をスキップするため、実際にはユーザーアクセスがトリガーになったものだけ再構築するようです。)
  ビューには更新オプションがあるため、これの調整などを組み合わせれば、実用も不可能ではないそうです。
• クリック可能な列のソート
  こ れらの列が増えてしまうと、結果的にはビューのインデックスが非常に大きくなり（列のソートをするということは、オリジナルのビュー相当なものを、もう１ つ作成するというイメージであり、例えばもともと10Mのビューに、４つのソート可能列を加えると、インデックスは50M程度になってしまう）、当然更新 にも時間がかかる、ということです。
• ドキュメントコレクション
  文書をつかんで、中身を取り出す場合、ビューに表示されているデータであるならば、ViewEntry関連のクラスを使ったほうが速いです。
  また、GetNextDocumentを使うときは(よく使いますよね)、「view.AutoUpdate = False」を使うのがよいようです。特にパフォーマンスの観点から。

いろいろなテクニックが紹介されていますが、今回は主にビュー特集というかんじです。Dominoの経験が長い方はご存知なテクニックが多いと思いますが、改めて見直すよい機会でもあったと思います。お行儀のよいアプリを作って、快適なDominoライフを。