V9+Pervasive V8のパフォーマンスについて
- depth:
- 0
前の投稿
-
次の投稿
|
親投稿
-
子投稿なし
|
投稿日時 2007-9-21 14:43
kondou
投稿数: 2
みなさんこんにちは。
V9のパフォーマンステストを行っているのですが、V7と比較して総じて遅くなっています。
グラフィカルな部分ならまだしもバッチで遅くなるというのは。。。
とりあえず一番簡単な全件READで質問です。
長文ですがお許し下さい。
ファイル構成はユニークキー(文字型)1つと文字型の項目1つというシンプルなもの。
レコード件数は1万件の全件ベタなめです。
■テスト環境
OS:Windows XP Pro SP2
MAGIC:V7.1B2 V9.4J SP6b
DB:Pervasive V8 SP3
CPU:Celeron 2.4GHz
Memory:512MB
■結果
V7.1B2:0.57秒
V9.4J SP6b:1.84秒
※Pervasive Control Centerの設定はデフォルト。/Extended=Y。
※共に端末起動直後でキャュシュは動作していないと思います。
たった1秒ちょいかと思われるかも知れませんが、3倍です。
レコード件数によっては、運用環境では困るレベルです。
■Pervasiveのmonitorの読込レコード件数
V7ですと1万件なのですがV9ですと倍の2万件となります。
V9ではタスク前で1万件で更にメインで1万件よんでいるように感じます。
サポセンの回答では、
全レコードを読み込み後、指定された位置にあるレコードの指定部分(チャンク)からデータを読み込みます。
その為に倍の読み込み件数になります。
との事。つまり正しい動作であると。。なんか腑に落ちません。。
もう少し調べると。。
メインファイルのインデックの有無でも読込件数が変わります。
※処理速度はインデックスの有無でさほど変わりません。
※テストは開発版によるものです。
◆V7
○総レコード件数1000件
・インデックス指定無:読込み件数→11件
・インデックス指定有:読込み件数→1000件
○総レコード件数10万件
・インデックス指定無:読込み件数→1087件
・インデックス指定有:読込み件数→100000件
◆V9
○総レコード件数1000件
・インデックス指定無:読込み件数→1011件
・インデックス指定有:読込み件数→2000件
○総レコード件数10万件
・インデックス指定無:読込み件数→101087件
・インデックス指定有:読込み件数→200000件
う〜んよくわかりません。
確かなのはインデックスを指定するとV7では実レコード件数、V9では2倍の件数になります。
■Pervasiveのログ
◆Ver7
open ab.dat (R,W,F) : Readonly (e:\)
buffering ON, selected only
=> BTRV() #58 OPEN (0 ) <= OK (0)
=> BTRV() #59 STAT (15) <= OK (0)
=> BTRV() #60 STAT (15) <= OK (0)
=> BTRV() #61 GET_GE (9 ) <= OK (0)
=> BTRV() #62 GET_POSITION (22) <= OK (0)
=> BTRV() #63 GET_NEXT_EXTENDED (36) <= KNW_END_OF_FILE (9)
=> BTRV() #64 GET_POSITION (22) <= OK (0)
=> BTRV() #65 GET_NEXT_EXTENDED (36) <= KNW_END_OF_FILE (9)
close e:\ab.dat
=> BTRV() #66 CLOSE (1 ) <= OK (0)
◆Ver9
open ab.dat (R,W,N) : Readonly (e:\)
BTRV() #144 OPEN (0 ) OK (0)
BTRV() #145 STAT (15) OK (0)
BTRV() #146 STAT (15) OK (0)
BTRV() #147 GET_GE (9 ) OK (0)
BTRV() #148 GET_POSITION (22) OK (0)
BTRV() #149 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #150 GET_NEXT_EXTENDED (36) KNW_END_OF_FILE (9)
BTRV() #151 GET_POSITION (22) OK (0)
BTRV() #152 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #153 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #154 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #155 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #156 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #157 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #158 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #159 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #160 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #161 GET_NEXT_EXTENDED (36) KNW_END_OF_FILE (9)
close e:\ab.dat
◆GET_NEXT_EXTENDED は確かにV9でも出力されていました。
V9では更に全件分の GET_DIRECT/CHUNK が発行されている!ようです。
これが遅い原因?
このGET_DIRECT/CHUNKは サポセンの回答ではV7での問題を解消するためということです。
ということはパフォーマンス改善はムリ?
GET_DIRECT/CHUNK とは何をしているのでしょうか?
PervasiveのV8 SDK マニュアルには
=================
Get Direct/Chunk オペレーション(B_GET_DIRECT) では、チャンクと呼ばれるレコードの部分を 1 つまたは複数取得で
きます。
=================
とあります。ログでは全レコードに対して発行しているように見えます。これではEXTENDEDの意味がないように思えます。
◆V7,V9共に、実行エンジン(MCF,MFF共に)では、GET_NEXT_EXTENDED ですが、開発エンジンでは
STEP_NEXT_EXT となります。
この違いは何でしょうか?
どなたか詳しい方、パフォーマンスをV7に近づける方法をご存知の方いらっしゃいましたらご回答宜しくお願い致します。
V9のパフォーマンステストを行っているのですが、V7と比較して総じて遅くなっています。
グラフィカルな部分ならまだしもバッチで遅くなるというのは。。。
とりあえず一番簡単な全件READで質問です。
長文ですがお許し下さい。
ファイル構成はユニークキー(文字型)1つと文字型の項目1つというシンプルなもの。
レコード件数は1万件の全件ベタなめです。
■テスト環境
OS:Windows XP Pro SP2
MAGIC:V7.1B2 V9.4J SP6b
DB:Pervasive V8 SP3
CPU:Celeron 2.4GHz
Memory:512MB
■結果
V7.1B2:0.57秒
V9.4J SP6b:1.84秒
※Pervasive Control Centerの設定はデフォルト。/Extended=Y。
※共に端末起動直後でキャュシュは動作していないと思います。
たった1秒ちょいかと思われるかも知れませんが、3倍です。
レコード件数によっては、運用環境では困るレベルです。
■Pervasiveのmonitorの読込レコード件数
V7ですと1万件なのですがV9ですと倍の2万件となります。
V9ではタスク前で1万件で更にメインで1万件よんでいるように感じます。
サポセンの回答では、
全レコードを読み込み後、指定された位置にあるレコードの指定部分(チャンク)からデータを読み込みます。
その為に倍の読み込み件数になります。
との事。つまり正しい動作であると。。なんか腑に落ちません。。
もう少し調べると。。
メインファイルのインデックの有無でも読込件数が変わります。
※処理速度はインデックスの有無でさほど変わりません。
※テストは開発版によるものです。
◆V7
○総レコード件数1000件
・インデックス指定無:読込み件数→11件
・インデックス指定有:読込み件数→1000件
○総レコード件数10万件
・インデックス指定無:読込み件数→1087件
・インデックス指定有:読込み件数→100000件
◆V9
○総レコード件数1000件
・インデックス指定無:読込み件数→1011件
・インデックス指定有:読込み件数→2000件
○総レコード件数10万件
・インデックス指定無:読込み件数→101087件
・インデックス指定有:読込み件数→200000件
う〜んよくわかりません。
確かなのはインデックスを指定するとV7では実レコード件数、V9では2倍の件数になります。
■Pervasiveのログ
◆Ver7
open ab.dat (R,W,F) : Readonly (e:\)
buffering ON, selected only
=> BTRV() #58 OPEN (0 ) <= OK (0)
=> BTRV() #59 STAT (15) <= OK (0)
=> BTRV() #60 STAT (15) <= OK (0)
=> BTRV() #61 GET_GE (9 ) <= OK (0)
=> BTRV() #62 GET_POSITION (22) <= OK (0)
=> BTRV() #63 GET_NEXT_EXTENDED (36) <= KNW_END_OF_FILE (9)
=> BTRV() #64 GET_POSITION (22) <= OK (0)
=> BTRV() #65 GET_NEXT_EXTENDED (36) <= KNW_END_OF_FILE (9)
close e:\ab.dat
=> BTRV() #66 CLOSE (1 ) <= OK (0)
◆Ver9
open ab.dat (R,W,N) : Readonly (e:\)
BTRV() #144 OPEN (0 ) OK (0)
BTRV() #145 STAT (15) OK (0)
BTRV() #146 STAT (15) OK (0)
BTRV() #147 GET_GE (9 ) OK (0)
BTRV() #148 GET_POSITION (22) OK (0)
BTRV() #149 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #150 GET_NEXT_EXTENDED (36) KNW_END_OF_FILE (9)
BTRV() #151 GET_POSITION (22) OK (0)
BTRV() #152 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #153 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #154 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #155 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #156 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #157 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #158 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #159 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #160 GET_DIRECT/CHUNK (23) OK (0)
BTRV() #161 GET_NEXT_EXTENDED (36) KNW_END_OF_FILE (9)
close e:\ab.dat
◆GET_NEXT_EXTENDED は確かにV9でも出力されていました。
V9では更に全件分の GET_DIRECT/CHUNK が発行されている!ようです。
これが遅い原因?
このGET_DIRECT/CHUNKは サポセンの回答ではV7での問題を解消するためということです。
ということはパフォーマンス改善はムリ?
GET_DIRECT/CHUNK とは何をしているのでしょうか?
PervasiveのV8 SDK マニュアルには
=================
Get Direct/Chunk オペレーション(B_GET_DIRECT) では、チャンクと呼ばれるレコードの部分を 1 つまたは複数取得で
きます。
=================
とあります。ログでは全レコードに対して発行しているように見えます。これではEXTENDEDの意味がないように思えます。
◆V7,V9共に、実行エンジン(MCF,MFF共に)では、GET_NEXT_EXTENDED ですが、開発エンジンでは
STEP_NEXT_EXT となります。
この違いは何でしょうか?
どなたか詳しい方、パフォーマンスをV7に近づける方法をご存知の方いらっしゃいましたらご回答宜しくお願い致します。
投票数:0
平均点:0.00
投稿ツリー
- V9+Pervasive V8のパフォーマンスについて (kondou, 2007-9-21 14:43)