IBM Business Process Manager 連載 : 事例に学ぶパフォーマンスの向上 第 3 回 画面描画の高速化
概要 IBM BPM は Coach フレームワークと呼ばれる画面のフレームワークを提供し CoachView と呼ばれる画面部品を組み合わせることによって効率よく画面を実装していくことが可能です しかしながら 1 画面に数百の単位の CoachView を配置した場合 画面の描画に要する時間が長くなり 期待する画面表示のパフォーマンスを実現することが難しくなるケースが多々あります 画面描画のパフォーマンスに影響する要素は様々ですが 本ドキュメントでは 主に CoachView の数に関するパフォーマンス問題についてその原因と パフォーマンス改善の方法について説明します Page 2
事象と事例 以下のようなケースでは 画面内の CoachView の数がパフォーマンスに影響しているため パフォーマンスを改善するためには画面構成を見直すことが必要です 1 画面に 500 個程度の CoachView を配置したところ 画面が表示されるまでに十秒以上かかるようになった 画面内にテーブルを配置したところ 画面が表示されるまでに数十秒かかるようになった 事例 : あるプロジェクトでは 画面内に巨大なテーブルを配置し業務データを一覧表示する必要があったが 画面が表示されるまでに数十秒を要していた そこで カスタムの CoachView を開発し CoachView の数を削減したところ 数秒で表示されるまでにパフォーマンスが改善した Page 3
問題の背景 IBM BPM は CoachView と呼ばれる画面部品を組み合わせ画面を効率的に開発することが可能です CoachView は javascript,html,css によって実装されていますが フレームワークの処理が含まれるため単純な CoachView であっても CoachView の数が増えるとそのオーバーヘッド分が無視できない大きさになります そこで 画面を開発する際には 1 画面内の CoachView の数が増えすぎないように注意が必要です 画面の構成やパフォーマンス目標 使用するマシンのスペック等にによって許容される 1 画面内の CoachView 数は異なりますが 100 個以上の CoachView を 1 画面内に配置する場合にはパフォーマンスが問題になるケースがあることを意識する必要があります 画面の描画コスト = Coach フレームワークのコスト CoachView の数 HTML javascript css のコスト CoachView1 つあたりのコスト 注 :HTML javascript css のコストに対するフレームワークのコストの比率は実装する機能によって異なります Page 4
CoachView の分類 CoachView として以下のものを利用可能です パフォーマンスの観点からは 製品標準のものよりも SparkUIToolkit に付属している CoachView が優れています また パフォーマンス チューニングのためのオプションも提供されます 複雑な画面を実装する際には SparkUIToolkit の採用を検討することを推奨します 名前 説明 Responsive Coaches Toolkit BPM8.5.7 からの製品標準の CoachView AngularJS ベース Coaches Toolkit( 非推奨 ) BPM8.5.7 以前に提供されていた製品標準の CoachView Dojo ベース Spark UI Toolkit Salient Process 社によって提供されている CoachView 今後 製品標準はこの CoachView のテクノロジーをベースに開発されていくことが決定している カスタム Coach View ユーザーによって 定義される CoachView Page 5
画面描画速度の改善アプローチ 画面描画の速度を改善するアプローチとしては CoachView1 つの描画コストを減らすか CoachView の数を減らすかのどちらかです 1CoachView の描画コストの削減 CoachView の実装を見直し CoachView1 つあたりの描画コストを小さくする 2CoachView の数の削減 画面を分割する タブを配置するなどして画面構成を見直す 粒度の小さな CoachView の集合を粒度の大きな CoachView に置き換える 1CoachView の実装を見直す Coach フレームワークのコスト HTML javascript css のコスト CoachView の数 2CoachView の数を減らす Page 6
1CoachView の描画コスト削減 CoachView の描画コスト削減とは すなわち軽量の CoachView の採用 開発ということになります 製品標準の CoachView を SparkUIToolkit に置き換えたり 製品標準の CoachView から必要のない機能を削除した CoachView を開発します カスタムで CaochView を開発する際には以下の点に注意します 使用する HTML のタグは最小限のものにする 必要以上に構成オプションの数を増やさない プロトタイプ レベルのイベントハンドラーを使用する CoachView の開発については以下のリンク先の文書を参照してください https://www.ibm.com/support/knowledgecenter/ja/ssfpjs_8.5.0/com.ibm.wbpm.wle.editor.doc/buildcoach/topics/tcreatingviews.html 製品が提供する CoachView を独自の CoachView に置き換える際には 将来のメンテナンスやサポートの観点も考慮して開発の是非を検討してください Page 7
1CoachView の描画コスト削減 Spark UI の利用 SPARK の UIToolkit で提供される CoachView は AngularJS などの他のフレームワークを使用しておらず シンプルな HTML/CSS で記述されているため パフォーマンスが優れています 単純に製品提供の CoachView を SPARK の CoachView に変更するだけでもパフォーマンスの改善が期待できます また 今後製品に統合されることが発表されているため サポートの面でも独自開発の CoachView と比較して優れています 特定の業務データに依存しない テキスト ボックスやチェックボックスといったプリミティブな画面部品としては Spark UI Toolkit の利用を推奨します Page 8
2CoachView 数の削減 画面の見直し 1 画面内に表示される CoachView の数を減らす方法としては以下のような方法があります 開発段階から CoachView の数がパフォーマンスに影響することを理解し CoachView の数をいたずらに増やさないようにします 画面を分割する タブを使用する 不要な CoachView を削除する 1 画面で大量の情報を表示 / 入力するのではなく 複数の画面に分けて表示 / 入力を行います パフォーマンス問題が表面化した後に画面を分割することを業務ユーザーと合意するのが難しいケースもあるため 画面をシンプルにすることのメリットを前もって理解してもらうことも重要です タブを用いることで非表示の CoachView の描画タイミングを遅延させることが可能です また SparkUIToolkit に付属する Deferred Section を用いることでも同等の効果があります レイアウトのためだけに使用している CoachView を削除し CSS などで代替します Page 9
2CoachView 数の削減 CoachView の粒度の変更 CoachView の粒度を大きくすることでも全体のパフォーマンスを向上させることが可能です 単純なテキスト表示や チェックボックスなどを多数配置するような画面では HTML や JavaScript の処理自体は軽いため フレームワーク部分のコストが大きくなります つまり テキストやチェックボックス 1 つづつでは無く 複数で 1 つの CoachView とすることで 全体のパフォーマンスは改善します フレームワーク部分のコスト HTML/Javascirpt/CSS のコスト テキスト ボックス 1 つを CoachView で実装 テキスト ボックス 5 つを 1 つの CoachView で実装 Page 10
2CoachView 数の削減 粒度と再利用性 画面部品の再利用性の観点からは CoachView の粒度は小さい方が好ましいですが 一方 パフォーマンスの観点からは CoachView の粒度は大きいほうが好ましいと言えます CoachView の粒度を決める際には 再利用性とパフォーマンスのバランスをとることが重要です 速 大 低 パフォーマンス 粒度 再利用性 遅 小 高 Page 11
テーブルの描画パフォーマンス改善例 次のようなカレンダー状の画面を CoachView によって実装するケースでの具体的な改善方法を検討します このようなテーブルを標準の CoachView を用いて表示しようとすると画面を構成するために必要な CoachView の数は 300 個近くになります 月 火 水 1 週 確認事項 A 確認事項 B 確認事項 A 確認事項 B -- 確認事項 C 確認事項 D 確認事項 C 確認事項 D 確認事項 E 確認事項 F 確認事項 E 確認事項 F 2 週 -- -- -- 3 週 -- -- -- 4 週 -- -- -- 5 週 -- -- -- テーブルセル垂直セクションチェックボックス合計 1 個 30 個 2x30 個 6x30 個 271 個 Page 12
テーブルの描画パフォーマンス改善例 具体的な改善方法は以下のとおりです 1 利用回数の多い CoachView( チェックボックス ) に着目し 軽量なチェックボックスを実装する 2 セル内で使用されている垂直セクションを削除し CSS 等で配置を調整する 3 チェックボックスは HTML で記述し セルレベルでの CoachView を実装する 4 テーブルレベルでの単一の CoachView として実装し テーブル内部は HTML で実装する 月 火 水 1チェックボックス の軽量化 1 週 確認事項 A 確認事項 B 確認事項 A 確認事項 B -- 確認事項 C 確認事項 D 確認事項 C 確認事項 D 確認事項 E 確認事項 F 確認事項 E 確認事項 F 2 週 -- -- -- 3 週 -- 2 垂直セクションの削除 -- 3セル レベルの CoachViewの実装 -- 4 テーブル レベルの CoachView の実装 4 週 -- -- -- Page 13 5 週 -- -- --
テーブルの描画パフォーマンス改善例 パフォーマンス改善効果については実際の画面を想定しての検証が必要ですが Spark を採用していないケースにおいては 個々の CoachView のコストが高いため 1 でもそれなりの効果が見込めます Spark をすでに採用しているケースにおいては 個々の CoachView の最適化の効果は小さくなります また 3 と 4 の実装の工数はそれほど大きく違わないため パフォーマンスを求めるのであれば 4 を採用することが効果的です 場合によっては描画速度が数分の 1 に短縮されるため 画面部品の再利用性はほぼ無くなりますが パフォーマンス要件を満たす必要がある場合には採用を検討する価値があります 月火水 1チェックボックス の軽量化 1 週 確認事項 A 確認事項 B 確認事項 C 確認事項 D 確認事項 E 確認事項 F 確認事項 A 確認事項 C 確認事項 E 確認事項 B 確認事項 D 確認事項 F 2 週 -- -- -- 3 週 -- 2 垂直セクションの削除 3セル レベルの -- -- CoachViewの実装 4 週 -- -- -- -- 4 テーブル レベルの CoachView の実装 Page 14 5 週 -- -- --
補足 :Spark におけるテーブルのオプション 製品標準のテーブルでは テーブルのセル内に配置した CoachView はそのまま CoachView として描画されるため セル数が多い場合には CoachView の数が増えてしまいます Spark のテーブルはセル内の CoachView を単純な HTML として描画するオプションがあり このオプションを利用した場合には描画のパフォーマンスが向上します 各カラムの設定で Simple HTML を指定することで単純な HTML として表示可能 Page 15
補足 :BO のサイズによるパフォーマンスの影響 CoachView の数の他に CoachView にバインドされている BO のサイズも画面のパフォーマンスに影響します パフォーマンスの観点からは CoachView にバインドする BO をできるだけシンプルなものにすることが重要です なるべく 実際に CoachView で使用するプロパティーのみをもつ BO にする 深い階層構造を持つことを避ける BO のサイズが非常に大きい場合などには 表示用の BO にデータを移し変えて利用します その際には データのマッピングの手間を減らすため マッピングするためのスクリプト / サービスを作成し 再利用します 大量の検索結果を BO にセットするようなケースでは データ必要なくなった時点で BO をクリアすることが有効なケースがあります Page 16
まとめ IBMBPM の画面描画のパフォーマンスに占める大きな要素が 1 画面に含まれる CoachView の数です CoachView の数を削減することでパフォーマンスを改善することが可能です CoachView の数を減らすには 1. 画面のレイアウトを変更する 2. 粒度の大きな CoachView を実装する の 2 つのアプローチがあります CoachView の粒度を大きくすれば大きくするほどパフォーマンスは向上しますが 部品としての再利用性が低下するため 両者のバランスをとってチューニングする必要があります Page 17
参照情報 IBM Business Process Manager V8.5 Performance Tuning and Best Practices http://www.redbooks.ibm.com/abstracts/sg248216.html?open IBM BPM Good Practice / Performance https://developer.ibm.com/bpm/docs/best-practices-recommendations/performance/ Page 18