> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
