公開コンテンツだれでも自由に閲覧できるコンテンツです。コンテンツの公開区分が指定されていない場合は、すべて公開コンテンツです。サポーターズコンテンツJPiereサポーターになると閲覧できるコンテンツです。JPiereのサポーターになって、オープンソースのERPのエコシステムを支援して下さい。トレーニングコンテンツ有料トレーニングで同様の内容を提供しているコンテンツです。有料トレーニングを受講する事でiDempiereを効率よく学ぶ事ができます。非公開コンテンツ公開していないコンテンツです。現在、JPiere/iDempiereのパフォーマンス検証の一環としてボリュームテストを実施しており、目標としている1億明細までもう少しといった所です。ボリュームテストでは受注伝票(10明細)->出荷納品伝票(10明細)->売上請求伝票(10明細)の登録をひたすら行っています。データ量が多くなってきたことに伴い、この受注伝票(10明細)->出荷納品伝票(10明細)->売上請求伝票(10明細)と登録するのに時間がかかるようになってきました。データ量も受注伝票明細で8000万明細を超えてきて受注伝票(10明細)->出荷納品伝票(10明細)->売上請求伝票(10明細)を1巡するのに10秒弱かかるようになり、ある程度遅くなるのはしょうがないかなと思っていたのですが、このままだと目標の1億明細までレコード数としてはあと少しでも時間的には結構かかってしまうので、なんとかならないかなと思って、ボトルネックとなっている所をソースコードを精査して探してみました。したら、ありました!!MInOutクラスのprepareIt()メソッドの中にある下記の処理がボトルネックとなっていました。)の中で、C_OrderテーブルのBill_BPartner_IDを条件にSELECT文を発行している所があるのですが、Bill_BPartner_IDにインデックスがはられていなかったため、受注伝票が増えるにしたがってパフォーマンスの低下につながっていました。^*)でも、これこそがボリュームテストを実施している成果ですね。データ件数が少ないうちは気が付くのは難しかったかなと思います。入金と一連の取引の流れでは、DBのインデックスはかなり最適化されたのではないかと思います。現在、受注伝票が900万伝票で明細が9000万明細近くになっていますが、伝票の登録、伝票ステータスの更新、転記と、とても元気に処理する事ができています。iDempiere/JPiereを使用されている方は、ぜひC_OrderテーブルのBill_BPartner_IDカラムにインデックスをはって下さい。がんばってインデックスをはりましたが、ボリュームテストでその効果を確認していくのはやっぱり大切ですね。これからもパフォーマンスについては継続的に追及してきたいと思っています。2012※このサイトは、iDempiereを中心としたOSSのERPに関する調査及び研究の成果を記録しておく事を目的とした個人のサイトです。