Thanks J for your reply. Actually my reports are dynamic in nature which means that until I get the dataset I do not know how many columns to show in report, what is the width of each column, which column will be placed at which position etc. user has the ability to add, remove, change column width, its position in report. So its not fixed and hence can not be templatized.
If there's any tool which can suffice these requirments, like any java API to generate PDF, or any template based product which can accommodate dymanic column configuration? I will highly appreciate any response. -----Original Message----- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Monday, May 15, 2006 3:28 PM To: [email protected] Subject: Re: FOP 0.92 Beta : Performance related question Singhal, Ramneek (Exchange) wrote: > I did tests on a > 2CPU(3.6GHz) linux machine with hyper threading on. I tried simulating > generation of 100 reports with 4 concurrent threads at a time and the > best output which I could achieve was 6.5 pages/sec. This sounds about right. > 1. is this the kind of performance we except or there is some problem > with the test results? Can I improve upon this performance by > optimising FO or hardware or anything? I have hardware infrastructure > to scale to 4 2CPU linux boxes. But even with those number of boxes, I > cannot get the desired output at current level of performance. It would be interesting to compare to a similar Windows box, in the past JVMs on Linux were notorious for having inferior JITC optimizations. I also think that for large reports, memory tuning should have more of an effect than higher powered CPUs, or hyper threading. I also suspect that for large reports, memory access is the bottleneck because of the large volume of working data, which has probably bad locality (thwarts caching). Therefore I wouldn't be surprised if FOP performance scales rather sublinear both in CPU freq and number of CPUs. Of course, that's just some sort of educated guess; running a professional profiler may uncover something completely different. Having said this, you should also know that FOP isn't yet tuned for performance; standard conformance and a reasonably modular design still have preference. The current line and page breaking algorithm will also always be a memory hog. An architecture which will allow plugging in alternative algorithms which are for example faster on average but give less impressive results has been considered, but put off until after FOP is feature complete. > 2. is FOP right approch for generating large amount of PDF reports in > a batch process? If its not can you suggest some other approach or > tools to do the job? If the reports are mainly tables, and the number of rows per page is easily predictable (preferably the same on every page due to fixed data size), using XSLFO is probably overkill. A simple template language combined with a text-to-PDF converter may be sufficient. XSLFO is a good tool if computing line breaks becomes an issue, and a professional layout with variable width fonts hyphenation and other such things is relevant. J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ********************************************************************** Please be aware that, notwithstanding the fact that the person sending this communication has an address in Bear Stearns' e-mail system, this person is not an employee, agent or representative of Bear Stearns. Accordingly, this person has no power or authority to represent, make any recommendation, solicitation, offer or statements or disclose information on behalf of or in any way bind Bear Stearns or any of its affiliates. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
