ラベル Bursting/バースティング の投稿を表示しています。 すべての投稿を表示
ラベル Bursting/バースティング の投稿を表示しています。 すべての投稿を表示

2011/08/03

レポートの翻訳 (Multiple Language Support with XLIFF)

BI Publisher は多言語のサポートはもちろん、レポートの翻訳機能も備えています。
従来のプログラミングでは、言語の切り替えを実装するためにリソースファイル(言語定義ファイル)を定義し、実行時に切り替える機能を実装する必要がありましたが、BI Publisher では、BI Publisher が自動で生成する定義ファイルに置き換える(翻訳する)単語を記載するだけで同等の要
件を満たすことができます。

大まかな流れは以下のブログに動画で説明されています。


実際のプロジェクトではほぼ確実に、各顧客や従業員または部門にファイルを一斉配信する際、つまりバースティングにおいて動的にレポートロケールを指定したいという要件が上がると考えられます。ここではこの要件に対応する方法を検証します。

【事前準備:データ】
今回は部門毎にレポートロケールが異なるという定義とします。具体的には、以下のようにscott.dept 表に列を追加し、ロケールを指定する文字列を設定します。
部門番号30が日本語、30がアラビア語の設定です。
alter table dept add (locCode varchar2(100));
update dept set locCode = 'en_US' where deptno = 10;
update dept set locCode = 'ja_JP' where deptno = 20;
update dept set locCode = 'ar_EG' where deptno = 30;
update dept set locCode = 'en_US' where deptno = 40;


【事前準備:XLIFF】
翻訳の定義ファイルを編集します。XLIFF(eXtensible Localization Interchange File Format)と呼ばれるXML形式です。
日本語とアラビア語のXLIFFファイルをアップロードします。アップロード後、以下の様に追加の翻訳用ロケールが表示されます。
Figure 1: Translation locale setting


【事前準備:バースティング定義】
バースティング定義では、分割及び配信キーにempnoを指定します。SQL問い合わせの設定は以下の通りです。
select
       empno              as key,
       'Layout1'          as template,
       dept.loccode       as locale,
       'RTF'              as template_format,
       'PDF'              as output_format,
       'FILE'             as del_channel,
       'false'            as save_output,
       'c:\workspace\'    as parameter1,
       to_char(emp.empno,'fm00000') || '_report.pdf'
                          as parameter2
  from emp, dept
 where dept.deptno = emp.deptno
 order by emp.empno

上記のSQLでは、ロケールをdept.loccodeから取得することで、各empnoに応じたロケールを設定します。出力の結果は以下の通りです。部門に応じた翻訳がなされていることが確認できます。

Figure 2: Report in English (deptno = 10, en_US)

Figure 3: Report in Japanese (deptno = 20, ja_JP)

Figure 4: Report in Arabic (deptno = 30, ar_EG)


なお、マニュアルは以下のURLを参照してください。
http://download.oracle.com/docs/cd/E24001_01/bi.1111/b63038/T527073T559221.htm

レポート、データモデルおよび結果のPDFファイルはこちらからダウンロードできます。

[Summary]
BI Publisher supports multiple language.  Also, you can easily translate your report with editing XLIFF (eXtensible Localization Interchange File Format) file.

The following blog post explains overall process.  Please see the movie.


In most of the cases, you would be asked to set appropriate report locale for each recipient.
This post explains how to burst report with changing the report locale dynamically.

[Data]
Add a column on scott.dept that stores the report locale.  In the sample below, dept# 10 is set to English, dept# 20 is Japanese, and dept# 30 is Arabic.

alter table dept add (locCode varchar2(100));
update dept set locCode = 'en_US' where deptno = 10;
update dept set locCode = 'ja_JP' where deptno = 20;
update dept set locCode = 'ar_EG' where deptno = 30;


[XLIFF]
Define the translation file.  create XLIFF files and upload.  See Figure 1.


[Bursting settings]
Set empno for Deliver by and Split by.  The SQL definition is as follows.  This SQL gets the report locale for each empno from dept table (dept.loccode).
select
       empno              as key,
       'Layout1'          as template,
       dept.loccode       as locale,
       'RTF'              as template_format,
       'PDF'              as output_format,
       'FILE'             as del_channel,
       'false'            as save_output,
       'c:\workspace\'    as parameter1,
       to_char(emp.empno,'fm00000') || '_report.pdf'
                          as parameter2
  from emp, dept
 where dept.deptno = emp.deptno
 order by emp.empno

The report (result) is shown in Figure 2 (in English), 3 (in Japanese) and 4 (in Arabic).


For more details, please refer to the manual below.

The report definition, data model and PDF results are available here.

2011/05/17

PDFセキュリティ (PDF security options)

BI PublisherのPDF出力オプションは「ランタイムオプション」で設定することができます。
Figure 1: Runtime property tab


【動的なオプション設定】
バースティングの際にファイル毎に個別の(異なる)パスワードを設定したい、という要件はほぼ確実に想定されます。このような場合には、上記の画面ではなく、テンプレートにて設定を行います。

以下のURLに方法が紹介されています。
http://blogs.oracle.com/xmlpublisher/2010/02/securing_burst_output_document.html


MS-Wordにて、ファイルのプロパティ画面を開きます。「ユーザ定義」タブを選択し、文書のプロパティにPDF出力オプションをあらわす文字列を埋め込みます。
以下の例では、PDFファイルのパスワードにempnoの値を設定します。


xdo-pdf-security:  true
xdo-pdf-open-password: {/ROWSET/ROW/EMPNO}
Figure 2: MS-Word property dialog



【オプションの一覧】
PDF出力オプションを以下に一覧します。
  • xdo-pdf-security
  • xdo-pdf-open-password
  • xdo-pdf-permissions-password
  • xdo-pdf-encryption-level
  • xdo-pdf-no-changing-the-document
  • xdo-pdf-no-printing
  • xdo-pdf-no-accff
  • xdo-pdf-no-cceda
  • xdo-pdf-enable-accessibility
  • xdo-pdf-enable-copying
  • xdo-pdf-changes-allowed
  • xdo-pdf-printing-allowed
これらのPDF出力オプションは以下のマニュアルに一覧されています。 http://download.oracle.com/docs/cd/E10383_01/doc/bip.1013/b40017/T421739T421745.htm#4419522



[Summary]
You can set PDF file options in Runtime Options tab (Figure1).


Runtime (dynamic) security setting
The setting above is static (fixed).
To achieve the requirement such as "set different password on each bursted PDF files", you need to set these security properties on the RTF template file.
To set file open password, define xdo-pdf-security and xdo-pdf-open-password on the file properties dialog (Figure 2).  In the example, the value of EMPNO is set for the password.
For details, please refer the following URL: (English)
http://blogs.oracle.com/xmlpublisher/2010/02/securing_burst_output_document.html


PDF Security options
The manual below helps you to find the property name.  Note that you need to add prefix "xdo-".

2011/05/12

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

BI Publisher 11gでの性能検証は、結論から申しますと失敗しました。1万ファイルへのバースティングに30分近く要する状況です。
VMの構成、およびJRockitの設定の見直しを行っているものの、芳しくありません。

この問題については今後、成功・失敗を問わず、事象に動きがあった段階でこのブログ上で公開したいと思います。


[Summary]
Performance test of BI Publisher 11g had not got good result so far - it takes around 30 minutes to burst the data into 10,000 files.
I suspend further investigation on this issue for a while.

2011/05/10

バースティング性能 その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.


2011/05/03

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

並列度と性能の関連について検証を続けます。

前回、2ファイルへの出力を行った際には2つのCPUコアの使用率が高まり、処理時間が短縮されました。今回は出力するファイルの数を増やして検証します。


【定義】
前回と同様、pagenoを基にファイルを分割します。3ファイルに出力する場合は trunc(pageno/3334)、4ファイルの場合は trunc(pageno/25001)という様にファイル分割のキーを算出します。

【結果】
結果は以下の通りです。縦軸が処理時間、横軸はファイル数です。
処理時間はファイル数の増加に従って短くなり、約50秒で頭打ちとなります。コア数は6ですが、4ファイル(スレッド)の段階で頭打ちとなっています。これは、6コアを割り当てているとは言ってもホストマシンのCPUに搭載されている物理コアが4つであることに起因している可能性があります。
Figure 1: Number of Files and Elapsed Time

 
サンプル数が少ないのが難点ですが、おおむね赤の点線で示したトレンドを確認することができます。


実績値は以下の通りです。秒間200ページほどの性能となります。この性能であれば、他の帳票生成ツールと比較しても高速な部類に入ります。
ファイル数#
所要時間(秒)秒間出力ページ数
3ファイル
1回目
53.6186.7

2回目
54.0
185.3
3回目
53.9
185.7
4ファイル
1回目49.3202.9

2回目48.4206.5

3回目49.0
204.3
5ファイル
1回目52.5190.4

2回目50.5198.0

3回目51.7193.3
6ファイル
1回目56.6
176.7

2回目55.6179.9

3回目56.1
178.3
7ファイル
1回目52.6190.2

2回目51.5194.3

3回目51.4194.4
10ファイル
1回目45.9217.7

2回目44.5224.7

3回目52.8
189.4


【検証時のOSの挙動】
並列度を上げた場合の負荷はCPUに集中します。
ここでは6ファイルの検証時のOS統計を確認します。

CPU:
処理中盤のピーク時、6つのコアすべての使用率が高まっていることが確認できます。
Figure 2: CPU usage

プロセッサ・キュー(System\Processor Queue Length)の状態もほぼ問題ありません。
Figure 3: Processor Queue Length


メモリ:
メモリの状態にも大きな問題はありません。
Figure 4: Memory usage



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


※チューニングについては後ほど検討します。


開発効率や信頼性の向上など、BI Publisherに限らず有償の商用ソフトウェアを採用する意義は様々ですが、今回の検証の様に、負荷に対するスケーラビリティがソフトウエア側で一定レベル保証されているという点も重要です。

今回で性能検証の前座は終了です。次回は本丸である「1ファイル1ページ」のバースティングを検証します。
※少数のファイルに多量のデータをバースティングする、という例がそもそもあまりよくありませんでしたが、前座ですのでご了承ください。


[Summary]

When the parallelism increase, how does it affect the processing performance?




[Results]
As shown in Figure 1, the elapsed time decreases as the number of thread increases.  Since the CPU of the host machine has four physical cores, four threads seems the performance ceiling.
The best performance is recorded as 200 pages per second - sounds nice anyway.  We will consider further tuning later.


[OS statistics]
CPU gets higher workload as parallelism grows.


CPU
All cores are near 100% (Figure 2).  Figure 3 shows Processor Queue wait 


Memory
No problem(Figure 4)


Disk
No problem(Figure 5)




Finally, this is the end of the appetizer.  Next time is the main dish - it is one page per one file .