サポート > リポジトリ > パフォーマンスチューニング

モデル設計を工夫することで、パフォーマンスの問題を改善することができます。

問題点

Wagbyが提供するリストボックスやラジオボタンは、大量データの選択には向いていません。ユーザーインタフェースの操作性から、選択肢として画面に表示される数は100件以下が妥当といえます。

このリストボックス(またはラジオボタン)を読み込み専用または隠し項目とし、かつ100件を超えるデータを保持させるような設計を行った場合、内部では選択肢を用意するため大量の SQL が発行されます。このような項目を多く含むモデル定義では、選択肢のデータ量が増加するに従い、パフォーマンスに問題が生じます。

図1 大量の選択肢をもったリストボックス

検索条件にも含めない

参照先モデルのデータ数が多いリストボックス(またはラジオボタン)を検索条件に含めた場合、そのモデルの一覧表示画面を開くときに時間がかかります。親子モデル関係にある親モデルの子モデル同時表示では、子のモデルの処理が遅くなることから、結果的に親モデルの画面を開くときに時間がかかるようになります。

解決策

大量の選択肢を持つモデル参照項目はリストボックスやラジオボタンではなく「検索画面」として定義してください。特に、もともと読み込み専用または隠し項目として設定していた場合は、見た目の影響もありません。

「検索画面」は選択肢を事前に作成しないため、SQL発行数を削減することができます。

問題点

Wagby では登録・更新画面でのリストボックス等の絞込方法として2通りの定義方法を提供しています。

[a] 方式は、いったん全ての選択肢データをデータベースから取得してから絞り込みを行います。そのため、大量の選択肢をもつ場合には不向きです。

[b] 方式は SQL の where 句を使って絞り込みを行うため、大量の選択肢があった場合でもパフォーマンスの問題が発生しにくいようになっています。

図2 「当社担当部署」を指定すると「当社担当者」の選択肢が変わる例

解決策

選択肢の数が多い場合は [b] 方式の利用を推奨します。

問題点

モデルAが、モデルBを参照している関係を例に説明します。

被参照モデル(B)に繰り返しコンテナ、チェックボックス項目などが定義されているとき、モデルAから当該モデルを参照するタイミングで、モデルBのこれら項目全てを SQL を使って読み込みます。しかし、モデルA 側では、これらの項目を利用しないことがわかっている場合、この SQL 処理は不要なものです。

図3 別テーブルのjoinが必要な場合

例えば、被参照モデルに「データの変更履歴」を保持させたとします。しかし多くの場合、これを参照するモデルでは、変更履歴情報を使うことはありません。しかし処理上は、被参照モデルをアクセスするタイミングで必ずデータの変更履歴を保持する繰り返しコンテナ(これは別テーブルです)も SQL で操作するため、パフォーマンスの観点からは好ましくありません。

解決策

被参照モデルに、必要最低限の項目のみを保持したサブモデルを用意します。

図4 メインモデルとサブモデル

サブモデルには主キー、非参照項目、表示優先度項目、無効判定項目、絞込項目等のモデル参照の際に利用される最低限の項目のみを定義します。参照モデルからは、このサブモデルを使うことで、不要な処理を抑制することができます。

問題点

外部データベースにあらかじめビューを用意しておき、Wagbyのモデルがこのビューを参照するような設計を行うことができます。

図5 ビューを参照させる

ここでビューのデータが不定期に更新される場合、Wagbyのモデルキャッシュ機構によって過去のデータを表示してしまう懸念が生じます。そのためモデルキャッシュを無効とすることができますが、これは当該モデルへの参照の都度、SQL を発行するため、パフォーマンス低下の要因になります。

解決策

次の方法をご検討ください。

  1. Wagbyのモデルキャッシュを有効とし、ジョブを使ってキャッシュ情報を定期的に消去する。
  2. データベースが提供する「マテリアライズドビュー」を使う。

詳細は"モデル > ビューの利用"をお読みください。

詳細画面で「前後のデータにアクセスする」ボタンを用意することができます。

Wagbyの一般的な画面操作は、(1) 検索 (2) 一覧表示 (3) 詳細表示となります。 ここで前後のデータにアクセスするボタンは、(2) の一覧表示の処理で取得した検索結果を使って、自分の前と後のデータを把握します。

この手順を踏まずに、直接 (3) の詳細表示画面へ遷移する場合、改めて内部で一覧データを取得する処理を行います。そのため、詳細画面の表示に時間を要します。

前後のデータにアクセスするボタンを無効とすることで、詳細画面の表示パフォーマンスを改善することができます。(標準では、本機能は有効となっています。)

複雑なSQL式はパフォーマンス低下の原因になることがあります。また、SQL式の項目を一覧表示のソート項目にしないような工夫も必要です。

親子モデル関係で、子モデルの要素全体に対する集合処理(COUNT や SUM など)を行なっており、第二引数に条件を指定する場合、モデル参照項目のID部を使って判断する処理は時間がかかります。子モデル一覧表示に ID 部を保持する隠し項目を用意し、この項目の値を使って判断するようにすることでパフォーマンスの向上につなげることができます。

またはWagbyが提供するCOUNTやSUM関数を使わず、代わりにスクリプトを使って計算結果を求めるという方法もあります。スクリプトでは適切な検索条件をセットしてDaoを呼び出すか、または直接、SQLを記述します。(利用するデータベースが提供するCOUNT,SUM関数を使うようにします。)

Wagby のスクリプトは実行時に毎回、スクリプトファイルの日付をチェックし、更新があった場合は再読み込みを行うようになっています。このチェック処理を行わないようにすることで、パフォーマンスを向上させることができます。

ビルドされたアプリケーション(wagbyapp)は、生成されたソースコードをコンパイルした .class ファイルが WEB-INF/classes フォルダに格納されています。これを一つの jar ファイルにまとめることで、起動時間を短縮することができます。

boostコマンド

Wagbyをインストールしたフォルダ内に misc フォルダが含まれています。コマンドプロンプトを開き、misc フォルダに移動します。次のコマンドを実行します。

boost
図6 boost の実行

このタスクは WEB-INF/classes のファイル群をまとめ、WEB-INF/lib フォルダに wagbyapp.jar を生成します。WEB-INF/classes 以下の .class ファイルは削除されます。これによって起動時間が高速になります。

その後のビルド処理

その後、Designer に戻ってモデル定義を変更し、差分ビルドを行うと WEB-INF/lib/wagbyapp.jar が再び WEB-INF/classes に展開されてからコンパイル処理が行われます。(注意:この展開のための時間が余分にかかります。)

フルビルドの場合は WEB-INF/classes および WEB-INF/lib/wagbyapp.jar の両方を消去し、クリーンな状態にします。

仕様・制約

boost 後は、check_db.bat などデータベース運用のための CUI コマンドが実行できません。これらのコマンドは boost 前に実行するようにしてください。または次のコマンドで、boost 状態を元に戻すことができます。

unboost