バースティング性能 その3 (Performance of the bursting function. Part 3)

これまでの検証で、1ファイルへの出力においてはCPUの1コアに負荷が集中し、処理のボトルネックが発生する傾向を確認しました。

特定のコア以外に負荷はかかっておらず、メモリやディスクにも余裕があると考えられます。このような状況下においては、処理速度の向上を図ってCPUのプロセッサを追加（コアを増加）しても意味はありません。
ここでは処理の並列実行（マルチスレッド実行）を検証します。BI Publisher 11g では、バースティングの際に自動的に並列処理を行ってくれます（10gまでは、「構成」メニューでバースティング時の並列度を手動で定義する必要がありました）。


【準備】
データモデル：
データソースのSQLは以下の通りです。各行のreport_id には０または１が設定されます。
select t.*,
       trunc(t.pageno/5001) as report_id
  from emp2 t
 order by 
       pageno, deptno, empno


バースティング定義：
5000ページ以前と、5001ページ以後の2つのファイルに分割して出力する定義です。分割、配信元にはともに report_id を指定します。
select distinct
       trunc(pageno/5001)     as key,
       'Layout1'              as template,
       'ja-JP'                as locale,
       'RTF'                  as template_format,
       'PDF'                  as output_format,
       'FILE'                 as del_channel,
       'false'                as save_output,
       'c:\workspace\'        as parameter1,
       'rp_' || to_char(trunc(pageno/5001)) || '.pdf'
                              as parameter2
from emp2

【結果】
処理時間はほぼ半減(123.6秒→67.2秒)しました。1秒あたりの出力ページ数も81.0枚から148.7枚と比例して増加しています。並列処理の効果は高いといえます。

	所要時間（秒）	秒間出力ページ数
1回目	67.7	147.6
2回目	67.3	148.7
3回目	66.7	149.8
平均	67.2	148.7

【検証時のOSの挙動】
BIサーバ(ゲストマシン２)の挙動を確認します。確認は、平均時間に近い3回目の実行時の統計情報をサンプルとします。

CPU:
開始後20秒間は1コアでの処理が行われています。この部分の動きは前回と変わりませんが、その後、2つのコア(Processor(2), Processor(4))に処理が分散されていることが確認できます。

Figure 1: CPU

メモリ：
前回同様、メモリには余裕のある状態です。

Figure 2: Memory

ディスク：
CPUへの負荷が1コアから2コアに切り替わるタイミングでスパイクが見られますが、大きな問題にはなっていません。

Figure 3: physical disk i/o

Figure 4: physical disk disk time(%)

※なお、前回は検証に %Disk Timeの値を使用していましたが、今回から「100 - %Idle Time」の値を使用します。これらの値については別途、説明します。



リソースに余裕のある状況では、バースティングの並列処理の効果が高いと考えられます。

---

[ Summary ]
It seems that a particular CPU core had been the bottleneck in the last test. BI Publisher was mainly working in a single thread.
You may suppose the other CPU cores, the memory and the physical disk can afford more load.
In the situation like this, adding another CPU processors does not mean anything.


This time, we see the parallel processing in a bursting job. BI Publisher 11g automatically performs multi thread.


[Settings]
Burst into two files. The data would be devided based on page number.


Data model:

select t.*,

       trunc(t.pageno/5001) as report_id

  from emp2 t

 order by 

       pageno, deptno, empno

Bursting:
Set "report_id" for Split by and Deliver by.

select distinct

       trunc(pageno/5001)     as key,

       'Layout1'              as template,

       'ja-JP'                as locale,

       'RTF'                  as template_format,

       'PDF'                  as output_format,

       'FILE'                 as del_channel,

       'false'                as save_output,

       'c:\workspace\'        as parameter1,

       'rp_' || to_char(trunc(pageno/5001)) || '.pdf'

                              as parameter2

from emp2

[Result]
The elapsed time is cut into 67.2 seconds, almost a half.

	Elapsed Time(sec)	pages / sec
1st	67.7	147.6
2nd	67.3	148.7
3rd	66.7	149.8
average	67.2	148.7

[OS statistics]
CPU:
It runs on a single core in the first 20 seconds. Then, two cores start to work (Figure 1).


Memory:
No problem (Figure 2).


Disk:
The disk spikes right before the second core starts to work - same as last time, not a big problem (Figure 3 and 4).
Note: This time, the value of disk time is "100 - %Idle Time" instead of %Disk Time.




[Conclusion]
When you have certain amount of available resources, it's worth to consider the parallel processing.