2016-10-24 5 views
1

Я столкнулся с проблемой производительности с использованием saxon и apache fo для преобразования xml в PDF. pdf, который мы используем для тестирования, имеет 85 страниц и составляет около 320 тыс. он тратит почти 2 минуты на преобразование метода и в локальном режиме занимает всего 5 секунд. мы отслеживаем использование процессора и GC во время этого вызова метода и обнаружили, что на сервере использование процессора остается стабильным на уровне 5%, и у нас не было ограничений на процессор с серверной стороны. GC происходит каждые 1-2 секунды, но все они являются второстепенными GC, и каждый занимает от 10 до 50 мс. мы также контролируем io wait во время теста, и он оставался очень низким.
Мы используем следующие файлы: saxon 9.1 и apache fop 2.1 (мы протестировали с различными версиями saxon и apache, но проблема осталась) Файлы xml и xsl слишком велики, поэтому я не могу их публиковать. ниже приведен пример кода преобразования:Saxon xslt преобразуется в PDF медленнее на сервере, но быстро на локальном

Я сомневаюсь, что возникла проблема с кодом, вызвавшая это, поскольку он работает нормально на локальном. очень благодарен за любые мысли по этому поводу!

ответ

1

Очевидно, что вы не предоставили достаточно информации для диагностики проблемы, поэтому все, что мы можем сделать, это дать рекомендации о том, как развернуть дальше, чтобы получить некоторые диагностические данные. Это будет намного легче помочь, если вы перейдете к текущей версии (9.7), и это может даже решить проблему.

Проверьте, выполняет ли преобразование любые HTTP-запросы на сервер W3C (или в другом месте). Например, для получения общих DTD. W3C намеренно дросселирует эти запросы. Последние выпуски Saxon перехватывают эти запросы и используют локальную копию файла в программном обеспечении Saxon, но вы используете очень старую версию. Существуют различные инструменты, которые вы можете использовать для мониторинга HTTP-трафика.

Проведите трансформацию самостоятельно без обработки Apache FOP, чтобы увидеть, как сравниваются цифры. Вам нужно определить, является ли проблема во время обработки XSLT или обработки XSL-FO, и лучший способ сделать это - запустить один без другого.

Проверьте, не возникают ли у вас одинаковые проблемы с производительностью при выполнении преобразования из командной строки.

Проверьте профиль исполнения саксона, полученный с помощью -TP: profile.html, и посмотрите, как результаты сравниваются на двух машинах.

Проверьте данные профиля Java, например. используя run = hprof и посмотрим, как он сравнивается на двух машинах. Любые серьезные различия дают ключ к дальнейшему исследованию.

+0

Спасибо за ответ. Я пробовал версии 9.7 и 9.6, вопрос все тот же. попробовал только генерировать fo файл и не использовать apache fo полностью, и этот шаг занимает всего 1 секунду. означает ли это, что медлительность была вызвана стороной apache fo? потому что я не уверен, выполняется ли саксонская работа при генерации fo или она также участвует в обработке FO в PDF. Также существует ли функция Saxon, которая генерирует PDF из FO? Спасибо –

+0

Если эти измерения правильны, ваши проблемы возникают в Apache FOP, а не в саксонии (что значит, извините, я не могу вам помочь). Saxon не участвует в преобразовании XSL-FO в PDF. –

+0

Спасибо, мы измерили время, потраченное на каждый другой шаг, и обработка XSL-fo для PDF заняла больше всего времени, поэтому кажется, что эта проблема возникает на стороне apache fop. –

Смежные вопросы