バースティング性能 その5(Performance of the bursting function part 5)

1ファイル1ページの出力を検証します。
残念ながら、BI Publisher 11g での検証は、VM上での検証が不調に終わったため、都合により、BI Publisher 10gでの検証結果を記載します。

【検証環境】

検証環境のBIサーバ構成を以下の通り変更します。

ゲストマシン2（BIEE）：
CPU: 4コア
Memory: 4GB
OS: Windows2003 Server, 32bit
BIEE: Oracle BIEE 10g

BI Publisher10gでは、マルチスレッド処理の設定を手動で行う必要があります。今回はコア数と同じ4スレッドでの実行を設定します。

Figure 1: Runtime property setting

【結果】
出力結果は以下の通りです。出力に3分以上かかる結果となってしまいました。

	所要時間（秒）	秒間出力ページ数
1回目	199.7	50.0
2回目	180.5	55.4
3回目	201.9	49.5
平均	194.0	51.7

平均で秒間約51ページの出力性能となりました。

【OS統計】
OS統計からは、ディスクおよびメモリに問題は見られません。
CPU使用率を確認すると、個々のコアの使用率が低く、かつ、断続的に落ち込んでいる状況が確認できます。

CPU:
バッチ処理としては、CPUリソースの能力を引き出せていません。全体で6割程度の使用率です。

Figure 2: CPU usage

メモリ:
メモリには余裕がある状態です。

Figure 3: Memory

ディスク:
ディスクアクセスにも問題はありません。

Figure 4: Disk time

【JVMのチューニング】
OS統計からは明確なボトルネック情報は得られませんが、CPUの動きからはGCが疑われます。
同時間帯のGCの様子を確認します。

Figure 5: Garbage Collection status (default setting)

Full GC （黒線）が多発しています。物理メモリにはまだ余裕がありますので、GCの間隔を広げるため、ヒープの絶対量を増やします。

最大サイズ(Xmx)を1GBに指定し、また、バッチ単体用途処理ですので、初期サイズ(Xms)も1GBに合わせます。併せて、パラレルGC (XX:+UseParallelGC)を設定します。参考まで、以下に追加･変更する設定を示します。
-Xmx1024M -Xms1024M -XX:+UseParallelGC

【再実行結果】

出力結果は以下の通りです。平均で約1分20秒、秒間約120ページの出力性能となりました。

	所要時間（秒）	秒間出力ページ数
1回目	82.3	121.5
2回目	82.3	121.5
3回目	84.0	118.9
平均	82.9	120.7

GCの頻度が低減し、スループット(下図のThroughput)も改善(79.32% → 95.93%)しています。これは、実行時間中にGCのためにJVMが停止した時間が大幅に減少したことを表しています。
今回はこれ以上のJVMの調査・チューニングは行いません。

Figure 6: Garbage Collection (Heap=1GB)

【OS統計】
CPU使用率が回復していることが確認できます。

CPU:

おおむね100%に近い使用率となっています。バッチ処理として、リソースの性能を引き出すことができています。

Figure 7: CPU usage

メモリ:
JVMにメモリを割り当てた分、空き容量は減少していますが問題はありません。

Figure 8: Memory

ディスク:
ディスクは余裕のある状態です。

Figure 9: Disk Time

1ファイルに1万ページをまとめて出力した場合のファイルサイズは19MBでしたが、1ページ1ファイル（本来のバースティング）の出力では、出力されるファイルの総サイズが458MB（1ファイルあたり46KB）に増加します。
PDFファイルを個別に出力する際のオーバーヘッドを勘案すると、ある程度妥当な性能と言えます。
これまで見てきたように、BI Publisher のバースティング機能はCPU性能に依存しますので、機器構成の検討の際にはインフラ担当者と密に連携し、性能検証を十分に実施することをお勧めします。

---

[Summary]
Now it's one page in each file.
Since BI Publisher 11g on my VM did not get good result, this time, I use BI Publisher 10g.  I may try 11g again in near future.


With BI Publisher 10g, you need to specify some parameters to implement multi thread bursting.  Figure 1 shows the setting.  Please refer the manual:
http://download.oracle.com/docs/cd/E10415_01/doc/bi.1013/e12187/T518230T522345.htm




[Result]
The result are as follows...  Not good.  It took three minutes over.

	Elapsed Time(sec)	pages / sec
1st	199.7	50.0
2nd	180.5	55.4
3rd	201.9	49.5
Average	194.0	51.7

[OS statistics]
OS statistics shows no bottleneck on memory nor disk (Figure 3 and 4).  You may see the CPU usage stays low (Figure 2).




[JVM Tuning]
BI Publisher runs on JVM, you should check the Garbage Collection behavior.  Figure 5 tells there had been too many Full GC.
The memory can afford more JVM heap.  Below is new setting:

-Xmx1024M -Xms1024M -XX:+UseParallelGC

[Result (with JVM heap size 1GB)]

It gets better.  The average is 120 pages per second.

	Elapsed Time(sec)	pages / sec
1st	82.3	121.5
2nd	82.3	121.5
3rd	84.0	118.9
Average	82.9	120.7

Figure 6 shows that the Full GC has been vanished.  You can see the Throughput in GC Viewer increased from 79.32% to 95.93%.  It means the pause time in JVM had been reduced a lot.

[OS statistics]

CPU usage gets higher.  It's around 98% (Figure 7).  This means BI Publisher uses the CPU resource effectively.

The memory and the disk stay calm (Figure 8 and 9).

The PDF file size is 46KB each, total 458MB (46KB * 10,000 files = 458MB).  In Part 1, the file size was 18.8MB.  The file size increased more than 20 times.

With consideration of the overheads (overhead when BI Publisher produces 10,000 individual PDF files), I accept this result.

The bursting function of BI Publisher is CPU-bound.  You should better to communicate with the infrastructure team to discuss the server spec.  The performance test should be done with them before they determine the spec, if possible.