> It works well, but it works slow.
> It takes about 5 minutes for 1,000 rows and this is only for transformer
> translation (excluing any data query time or jdom XML building time)
When you prepare an actual FO file for us to see, please check how long
xalan takes for the xml->fo translation step. Just to make sure..
As for your XML file: you may want to try rewriting the elements below
the <row> node as attributes of the row node. Since you are generating the
files on the fly, this should improve performance a little. With 1000 row
elements, thats about 10000 less nodes to process. If and how much this
saves
depends on the DOM and xslt processor you use, of course.
In general, I find the 5 minutes you state a little long. FOP does have
severe
performance problemes with large tables, but not that bad. We generate a
30
page document of this kind in about 40 seconds on a 1Ghz Athlon.
One thing that you could try is to increase the java heap to 1024MB. 512MB
is
not excessive for the kind of document you state. Maybe you don't get out
of
memory messages so far, but if memory is tight, the JVM will garbage
collect
a lot - and this is costly for FOP. Try to find a heap size where no
garbage
collection is necessary during processing of a single document.
One other thing: If you generate PDFs that are costly in terms of CPU
and/or memory,
think about generating the PDFs in the background, then email them to your
web site's visitors. If your use case could live with that, I'd go that
route.
Even with a FOP that's 20 times faster, you'll have a hard time
guaranteeing
a certain quality of service for your web site. At the very least, you'd
have
to use a rendering queue with a pool of renderers since you don't have
infinite
memory (I suppose).
Hope this helps,
Arnd Beissner
--
Cappelino Informationstechnologie GmbH
Arnd Beißner
|
