【iDempiere Lab】JPiereのボリュームテストメモ-900万伝票9000万明細

JPiereを使用したボリュームテストのメモ。

基本的な操作は問題なく行えている。このレベルになると、登録専用の画面を作成し、更新の際には検索ウィンドウよりズームするようにするなど、操作的に大量ボリューム対応できるように準備しておく必要があると感じる。

JPiereでは、大量ボリュームを意識した各種設定を予め施しています。詳しくは"JPiereのパフォーマンス改善への取り組み"を参照して下さい。

 

テスト環境

Windows10 - 64bit ノートPC

  • Intel Core i7 - 4510U CPU @2.00GHz
  • メモリ16GB
  • SSD(※ただしボリュームテストのDBはUSB3接続の外付けSSD)
  • PostgreSQL9.4

DB概要

USB3接続の外付けSSD(2TB)にデータを格納。

DBサイズ:約468GB

【補足説明】

データボリュームによるパフォーマンスの違いを検証するために、次のテーブルのレコードをいったんすべて削除しました。

  • M_CostDetail
  • M_CostHistory

検証の結果としては、上記のテーブルのレコードを削除しても、出荷納品伝票や入荷伝票の登録パフォーマンスに好影響がある事は確認できませんでした。

【補足説明】インデックスの追加

C_OrdetテーブルのBill_BPartner_IDにインデックスを追加。これにより、出荷納品伝票の登録スピードが大幅に向上しました。

[インデックス追加理由]

出荷納品伝票のprepareIt()メソッドで、C_OrderテーブルのBill_BPartner_IDを条件指定し未請求の金額をSQLで計算している処理があり、受注伝票が多くなるにつれて出荷納品伝票の伝票ステータスを完成にする処理が重くなっていた。そのため、このインデックスを追加した。

[関連するコンテンツ]

主なマスタ情報

取引先マスタ - 10万件

◆C_BPartnerテーブル情報

  • レコード件数(Count関数使用):100,125
  • テーブルサイズ(統計情報参照):47MB
  • インデックスサイズ(統計情報参照):40MB

品目マスタ - 10万件

◆M_Productテーブル情報

  • レコード件数(Count関数使用):100,080
  • テーブルサイズ(統計情報参照):31MB
  • インデックスサイズ(統計情報参照):23MB

販売管理と購買管理

受注伝票と発注伝票 - 合計902万伝票 7,059万明細

1伝票10明細で伝票登録。

受注伝票(標準入力:登録専用)ウィンドウと発注伝票ウィンドウ(標準入力)において、通常通り伝票登録できる事を確認した。

◆C_Orderテーブル情報

  • レコード件数(Count関数使用):9,025,874
  • テーブルサイズ(統計情報参照):3,753MB
  • インデックスサイズ(統計情報参照):2,807MB

◆C_OrderLineテーブル情報

  • レコード件数(Count関数使用):90,317,416
  • テーブルサイズ(統計情報参照):27GB
  • インデックスサイズ(統計情報参照):15GB

 

出荷納品伝票と入荷伝票 - 合計902万伝票 9,031万明細

1伝票10明細で伝票登録。

受注伝票をもとに出荷納品伝票を作成し、通常通り伝票登録ができる事を確認した。同様に、発注伝票から入荷伝票を作成し、通常通り伝票登録ができる事を確認した。

◆M_InOutテーブル情報

  • レコード件数(Count関数使用):9,025,803
  • テーブルサイズ(統計情報参照):3,218MB
  • インデックスサイズ(統計情報参照):2,789MB

◆M_InOutLineテーブル情報

  • レコード件数(Count関数使用):90,317,270
  • テーブルサイズ(統計情報参照):17GB
  • インデックスサイズ(統計情報参照):12GB

 

発注照合伝票 - 合計391万伝票

◆M_MatchPOテーブル情報

  • レコード件数(Conut関数使用):3,916,109
  • テーブルサイズ(統計情報参照):996MB
  • インデックスサイズ(統計情報参照):1748MB

 

売上請求伝票と仕入請求伝票 - 合計919万伝票 9,204万明細

1伝票10明細で伝票登録。

売上請求伝票(標準入力:登録専用)ウィンドウで受注伝票をもとに売上請求伝票を作成し、通常通り伝票登録ができる事を確認した。同様に仕入請求伝票(標準入力)でも通常通り、伝票登録ができる事を確認した。

◆C_Invoiceテーブル情報

  • レコード件数(Count関数使用):9,198,433
  • テーブルサイズ(統計情報参照):3,411MB
  • インデックスサイズ(統計情報参照):7,118MB

◆C_InvoiceLineテーブル情報

  • レコード件数(Count関数使用):92,042,959
  • テーブルサイズ(統計情報参照):21GB
  • インデックスサイズ(統計情報参照):15GB

請求照合伝票 - 合計391万伝票

◆M_MatchInvテーブル情報

  • レコード件数(Conut関数使用):3,911,707
  • テーブルサイズ(統計情報参照):938MB
  • インデックスサイズ(統計情報参照):1459MB

 

債権債務管理

入金伝票と支払伝票 - 合計862万伝票

ひと月ごとに売上/仕入請求伝票をまとめて支払う想定で入金/支払処理を実行。

入金伝票を、通常通り登録し、消込処理画面で消込処理が行えることを確認した。

◆C_Paymentテーブル情報

  • レコード件数(Count関数使用):8,625,882
  • テーブルサイズ(統計情報参照):2,862MB
  • インデックスサイズ(統計情報参照):4,495MB

 

消込伝票 - 合計840万伝票

ひと月ごとに売上/仕入請求伝票をまとめて支払う想定で入金/支払処理を実行。

◆C_AllocationHdrテーブル情報

  • レコード件数(Count関数使用):8,409,074
  • テーブルサイズ(統計情報参照):2,251MB
  • インデックスサイズ(統計情報参照):3,156MB

◆C_AllocationLineテーブル情報

  • レコード件数(Count関数使用):8,594,134
  • テーブルサイズ(統計情報参照):1,491MB
  • インデックスサイズ(統計情報参照):1,433MB

 

出納帳

◆C_BankStatementテーブル情報

  • レコード件数(Count関数使用):12,018
  • テーブルサイズ(統計情報参照):19MB
  • インデックスサイズ(統計情報参照):34MB

◆C_BankStatementLineテーブル情報

  • レコード件数(Count関数使用):8,513,038
  • テーブルサイズ(統計情報参照):2,035MB
  • インデックスサイズ(統計情報参照):2,046MB

在庫管理

在庫管理台帳テーブル情報

◆M_Transactionテーブル情報

  • レコード件数(Count関数使用):92,278,906
  • テーブルサイズ(統計情報参照):15GB
  • インデックスサイズ(統計情報参照):11GB

◆M_StorageOnHandテーブル情報

  • レコード件数(Count関数使用):7,968,987
  • テーブルサイズ(統計情報参照):1,306MB
  • インデックスサイズ(統計情報参照):2,045MB

◆M_StorageReservationテーブル情報

  • レコード件数(Count関数使用):1,000,115
  • テーブルサイズ(統計情報参照):172MB
  • インデックスサイズ(統計情報参照):374MB

会計

FACT_ACCTテーブル情報 3億5千万レコード

  • レコード件数(Count関数使用):349,689,285
  • テーブルサイズ(統計情報参照):112GB
  • インデックスサイズ(統計情報参照):74GB

 

関連するコンテンツ