FOP, получение постоянных результатов при создании PDF - PullRequest
Новая
       32

FOP, получение постоянных результатов при создании PDF

2 голосов
/ 27 октября 2011

У нас возникли проблемы, связанные с исполнением 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. Загрузка нашего шрифта с использованием параметра каталога или загрузка каждого шрифта с тегом шрифта
  2. Установка stric-конфигурации в true
  3. Установка строгой проверки в false
  4. Использование файла кэша (тега cache-file)

Ничто существенно не улучшит производительностьпо первому звонку.Наше единственное решение на данный момент состоит в том, чтобы сгенерировать поддельный pdf в конструкторе, так что первый вызов будет искусственно выполнен при запуске jvm.

Есть ли у вас какие-либо предложения по сглаживанию производительности и, возможно, некоторые объяснения этого поведения?

Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 27 октября 2011

Как часто базовые ресурсы меняются в сгенерированном PDF?

Я работал с FOP раньше, у меня были примерно те же проблемы, и я никогда не находил способ их обойти (даже если они есть),

В ретроспективе я бы попытался создать PDF-файл всякий раз, когда основные ресурсы сохраняются;и затем сериализуйте это в противоположность предоставлению по требованию.Затем, когда приходит запрос, просто возвращайте самый последний сериализованный PDF.Даже если вы в конечном итоге создадите PDF-файлы, которые никогда не используются;это значительно сократит время для пользователя, чтобы получить их PDF;скорее всего, больше, чем сейчас.

0 голосов
/ 27 октября 2011

Это эффект загрузки классов Java и JIT (компиляция точно в срок), так называемый прогрев JVM.JVM постепенно повышает производительность, поскольку видит потенциал для оптимизации.Если вы выполните, скажем, 100 вызовов, вы в конечном итоге увидите более или менее постоянную производительность.Вы просто ничего не можете сделать, чтобы изменить это, и то же самое применимо к любому приложению Java.

Возможно, вы можете переключиться на клиентскую виртуальную машину (-client в качестве параметра JVM), если вы в данный момент используете серверную виртуальную машину (который по умолчанию с 64-битным процессором).Это может немного уменьшить эффект, который вы видите, но, вероятно, не сильно.

...