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

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

問題点

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

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

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

解決策

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

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

問題点

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

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

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

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

解決策

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

問題点

モデルAが、モデルBを参照している関係を例に説明します。ここでモデルBはマスター用途のモデルとします。

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

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

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

解決策

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

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

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

問題点

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

図5 ビューを参照させる

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

解決策

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

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

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

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

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

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

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

Wagby Developer Day 2017