JPiereのパフォーマンス改善への取り組み

オープンソースのERP iDempiere(アイデンピエレ)の初期設定の状態は、残念ながらiDempiereのポテンシャルを最大限に発揮できる状態にはなっていません。そこで、JPiere(ジェイピーエール)ではiDempiereのポテンシャルを最大限に引き出させるように、継続的に調査及び研究し、その成果を反映しています。

インデックスの追加

iDempiereの初期設定状態では、残念ながらデータベーステーブルに対して最低限必要となるインデックスが適正に設定されているとは言えません。そこで、JPiereでは最低限必要となると思われるインデックスを予め設定しています。

【JPIERE-0179】トランザクションテーブルへのインデックス追加

【JPIERE-0383】受注伝票明細に処理中の注文(IsProcessingOrderJP)フラグ追加

【JPIERE-0384】得意先返品受付伝票明細に処理中の返品(IsProcessingRMAJP)フラグ追加

【JPIERE-0386】主要マスタテーブルへのインデックス

【JPIERE-0429】システム設定関連テーブルへのインデックス

パラメータ設定によるカスタマイズ

iDempiereの初期状態の各種パラメータ設定はパフォーマンス的に最善の状態とは言えませんし、データが大量になった場合の備えも充分に出来ているとは言えません。そこで、JPiereではパフォーマンスとデータが大量になった場合を考慮した設定を施しています。

最近のアクセス項目ガジェットに非アクティブ化

iDempiereの標準のガジェットである最近の更新したデータを表示する"最近のアクセス項目"のガジェットを使用していると、ウィンドウでデータを保存した際に負荷が増えます。JPiereでは"最近のアクセス項目"ガジェットの使用頻度はあまり高くないと判断し、JPiereの初期設定では非アクティブにしています。

使用したい場合は、アクティブ化する事で簡単に使用する事ができます。

参照  【iDempiere Lab】最近のアクセス項目ガジェットの復活!!

ウィンドウの一覧表示に表示するフィールドは必要最小限にする

ウィンドウの一覧表示に表示するフィールドが多くなればなるほど、パフォーマンス的には悪くなります。そこでJPiereでは主要なウィンドウでは一覧表示するフィールド数を厳選し、パフォーマンスの改善を図っています。

ウィンドウの一覧表示でページングするレコード件数を少なくする

ウィンドウの一覧表示で1ページあたりの表示レコード件数が多くなると、それだけパフォーマンス的には悪くなります。iDempiereの初期設定では1ページあたり25件のレコード件数を、JPiereでは20件に変更しパフォーマンスの改善を図っています。

更新履歴のログの取得は必要最小限にする(不要な更新履歴は取得しない)

iDempiereはデータベーステーブルのカラム毎に、更新履歴としてログを記録するかどうか、細かく設定する事ができます。しかし一方でログを記録する事は、更新処理のパフォーマンスに影響がありますし、記録すればその分だけHDDなどの記憶領域を使用します。

iDempiereの初期設定では、多くのカラムでログを記録するようになっていますが、JPiereの初期設定ではログを記録しないようにしています。JPiereの導入時にログを記録すべきカラムを厳選して、ログを記録するように意図しています。

【補足説明】ログを記録しなくても、レコードの作成者と直近の更新者の情報は記録されています。

ログを記録しなくても、iDempiereではレコード自体に、そのレコードの作成者と作成日、直近の更新者と更新日が記録されています。

リファレンスの設定はTableやTableDirectよりSearchを使用する

アプリケーション辞書のリファレンスの設定は、少ながらずパフォーマンスに影響があります。そこでJPiereではリファレンスの設定を随時見直して、パフォーマンスの改善を図っています。

データ登録専用のウィンドウ作成

　iDempiereの初期設定では、データの新規登録も更新も同じウィンドウで行えるようになっていますが、データ件数が多くなると新規登録ウィンドウと更新ウィンドウに分けた方が、パフォーマンス的に好ましいです。そこで、JPiereでは下記のウィンドウをそのサンプルとして登録しています。

  • 受注伝票(標準入力：登録専用)
  • 売上請求伝票(標準入力：登録専用)

伝票の検索ウィンドウ

ウィンドウの虫眼鏡アイコンの検索では、検索条件の必須入力が指定ができないため、大量のデータになってくるとインデックスが有効に機能せず検索パフォーマンスが悪い場合があります。データ量が多い場合は、検索ウィンドウでインデックスが有効に機能する検索条件を必須検索条件に指定にして、レコードを検索し、ズームしてウィンドウで表示する操作フローが好ましいです。そのため、JPiereではほとんどの伝票で予め検索ウィンドウを用意しています。

などなど…

ソースコードレベルのカスタマイズ

iDempiereのソースコードを少し修正する事でパフォーマンスが改善につながる場合があります。ここではソースコードレベルでパフォーマンス改善のために行ったカスタマイズを紹介します。

【JPIERE-0120】右サイドのヘルプ表示なしデフォルトデスクトップ

オープンソースのERP iDempiereのデスクトップ(デフォルトデスクトップ)は、画面の右側にヘルプが表示されるようになっています。画面の表示が切り替わった時や、フィールドからフィールドへフォーカスが移った時などに、このヘルプの表示も切り替わります。ヘルプを参照している人にとっては、これはすごく便利なのですが、ヘルプを参照しない人にとっては、まったく無駄な動きです。実際、iDempiereの操作になれれば、このヘルプを参照にする人は、ほとんどいないでしょう。

そのため、JPiereでは、その右側のヘルプを表示しない事により、無駄な処理を無くし、パフォーマンス向上させています。

【JPIERE-0181】FindWindowクラスのパフォーマンス改善

iDempiereの標準データ入力画面であるウィンドウは、画面を表示する際に表示対象となるデータの件数をカウントしています。そのカウント処理のロジックをカスタマイズして改善しています。

【JPIERE-0264】一覧レポートの表示レコード数の制限

データ量が多くなってくると、一覧レポートの表示の際に、思わず大量データの表示を実施してしまい、システム的に負荷が高くなる事があります。そのような事を防ぐために、一覧レポートに表示するレコード数を制限できるようにしています。

【JPIERE-0283】PostgreSQLのSQLキャッシュリセット

PostgreSQLで実行されるSQLは、iDempiere上でキャッシュされています。キャッシュしているSQLの中には、めったに使用しないようなSQLも多数あり、定期的にキャッシュをリセットしないと、無駄なキャッシュでメモリ(Javaのヒープメモリ)を浪費しています。そのためJPiereではSQLのキャッシュだけをリセットするプロセスを作成し、定期的に実行するように初期設定しています。

関連するコンテンツ

【JPIERE-0370】出荷納品伝票のprepareIt()メソッドのパフォーマンス改善

出荷納品伝票の伝票ステータスを完成にする際に、prepareIt()メソッドで与信のチェックをおこなっています。しかし、この与信のチェック処理において、与信チェックが必要のない場合に対しても、未請求金額を計算しているため、無駄な処理となる場合があります。 そこで、与信チェックが必要のない場合は、未請求金額をそもそも計算しないように改善しました。

JPiereのボリュームテスト

JPiereでは、ボリュームテストを実施して、大量データに対応できるように調査及び研究しています。

【ポイント】JPiereでは継続的にパフォーマンスの改善に取り組んでいます。

ここで紹介したパフォーマンス改善の取り組み以外にもiDempiere/JPiereのパフォーマンスを改善する手法はあります。しかし、パフォーマンスの改善は一朝一夕にはできず、継続的に行っていく必要があります。JPiereでは、パフォーマンスの改善に継続的に取り組んでいます。

 

関連するコンテンツ