FOP、pdf生成に関する一定のパフォーマンスを得る

我々は、複数回の呼び出しでfop(v0.95)のパフォーマンスに関する問題を抱えています。我々は、いくつかの画像と独自のフォントを含むPDFを作成しています。

最初の呼び出しは他の呼び出しよりはるかに長く、それは私たちにとって問題です。いくつかの呼び出しの例を示します(時間はミリ秒です):

  • 通話1 - 経過時間= 13929
  • 電話番号2 - 経過時間= 2817
  • 電話番号3 - 経過時間= 3312
  • 電話番号4 - 経過時間= 1629
  • 電話番号5 - 経過時間= 1436
  • 電話番号6 - 経過時間= 1356
  • 電話番号7 - 経過時間= 911
  • 電話番号8 - 経過時間= 1244
  • コール#9 - 経過時間= 780
  • コール#10 - 経過時間= 895

これを修正するためにいくつか試みました。

  1. 代わりにdirectoryパラメータを使用してフォントを読み込む フォントタグを持つ各フォント
  2. stric-configurationをtrueに設定する
  3. 厳密検証をfalseに設定する
  4. キャッシュファイル(cache-fileタグ)の使用

最初のコールのパフォーマンスを大幅に改善するものはありません。私たちの唯一の解決策は、コンストラクタで偽のpdfを生成して、最初の呼び出しがjvm startで人為的に行われるようにすることです。

あなたはパフォーマンスをスムーズにするための提案がありますか?

前もって感謝します。

2

2 答え

これは、JavaクラスのロードとJIT(ジャストインタイムコンパイル)の効果、いわゆるJVMウォームアップです。 JVMは、最適化の可能性を見て徐々にパフォーマンスを向上させます。あなたが100回の呼び出しを実行すると、最終的には、一定のパフォーマンスが見られるでしょう。これを変更するだけで何もできません。すべてのJavaアプリケーションに同じことが適用されます。

現在Server VM(64ビットCPUでデフォルト)を実行している場合は、Client VM(JVMパラメータとして-client)に切り替えることができます。それはあなたが少し見ている効果を軽減するかもしれませんが、多分そうではありません。

0
追加された
@jakcam:JIT/Startup時間(重要なことがあるできる)に加えて、最初の呼び出しを除くすべてのバッファで事前に満たされたバッファを処理します(つまり、OSは既にすべての必要なリソースを読み、ディスクを2番目、3番目、...の周りに回転させる必要があります)。
追加された 著者 Joachim Sauer,
私はあなたに同意するJITは4-5コール後のパフォーマンスを向上させる(私は自分の考えを確認するネット上のいくつかの参照を参照してください)。しかし、私は最初の呼び出しに14秒かかり、2回目には6倍もかからない理由を説明することはできません。ありがとう。
追加された 著者 jakcam,

生成されたPDF内で、基になるリソースがどのくらいの頻度で変更されますか?

私は前にFOPで働いていて、おおよそ同じ問題を抱えていて、まったく同じ問題を抱えていませんでした。

私が思うには、基礎となるリソースが永続化されるたびにpdfを生成することです。オンデマンドでのレンダリングとは対照的に、それを直列化します。次に、リクエストが来たら、直近のシリアライズされたpdfを返します。決して使用されないPDFを生成する可能性があります。ユーザーが自分のpdfを入手する時間が大幅に短縮されます。あなたが今見ている時よりもおそらくもっとそうです。

0
追加された