30 pages is not our absolute max, but we have set a requirement that we have to be able to handle at least two concurrent reports, so we need some cushion. I have attached some FO for a report that runs around 50 pages, using only one page-sequence. I would really appreciate it if you coule run it through your FOP processor and tell me what kind of performance you see. It runs on our system, but two of these at once will come very close to an out of memory error. I have a feeling the large performance discrepancy may be because our report is one large table. Please let me know what you find.
Below is the log output for a slightly larger (66 page) report also using only one page-sequence. I had to do some de-indefication to create the report I attached. But this log output is from the exact same report, just slightly different data. As you can see at -mx256m, we come close to an out of memory error on just this report. Once we implemented the page-sequence chunking though, full garbage collection knocks memory-in-use down to the range of 25-75MB depending on the report. This is a big improvement over the 215MB that you still see in use below even after a full GC. This was run on my Windows dev box (PIII 850Mhz 512MB ram) set to -mx256m. Memory performance and speed are always much worse on our production boxes( HP-UX, 2x550 RISC, 2GB ram) set to -mx512M -- especially on 2 or more concurrent reports. We're trying to talk our infrastructure police into letting us set up a Win2k server with Weblogic as a dedicated PDF report generator. No luck yet. [GC 41503K->39768K(216920K), 0.0604714 secs] [GC 41816K->40081K(216920K), 0.0734613 secs] (... FOP processing begins below ...) building formatting object tree setting up fonts [GC 42128K->40544K(216920K), 0.0598146 secs] [GC 42592K->41074K(216920K), 0.0308461 secs] (... many more partial garbage collections ...) [GC 113914K->112394K(216920K), 0.0217497 secs] [GC 114442K->112925K(216920K), 0.0222277 secs] [GC 114973K->113455K(216920K), 0.0222500 secs] [GC 115503K->113983K(216920K), 0.0219170 secs] (... FOP is done pre-processing, page generation begins ...) [1[GC 116031K->114464K(216920K), 0.0214575 secs] [GC 116512K->114883K(216920K), 0.0216715 secs] [GC 116931K->115305K(216920K), 0.0224520 secs] [GC 117353K->115722K(216920K), 0.0233072 secs] ] [2[GC 117770K->116113K(216920K), 0.0208135 secs] [GC 118161K->116531K(216920K), 0.0223947 secs] [GC 118579K->116951K(216920K), 0.0220651 secs] ][GC 118999K->117329K(216920K), 0.0211273 secs] [3[GC 119377K->117768K(216920K), 0.0220210 secs] [GC 119816K->118186K(216920K), 0.0219897 secs] [GC 120234K->118606K(216920K), 0.0223495 secs] (... pages 4-62 output and steady partial garbage collection ...) [63[GC 212110K->210967K(216920K), 0.0201827 secs] [GC 213011K->211792K(216920K), 0.0224984 secs] [GC 213370K->212929K(216920K), 0.0238419 secs] [GC 214977K->214223K(216920K), 0.0349902 secs] [GC 216271K->215075K(217464K), 0.0221023 secs] (... full garbage collection, at this point we know most memory in use is for FOP ...) (... IE - normal full garbage collection brings memory in use down to ~20MB ...) (... So at -mx256m, FOP is ~40MB away from an out of memory error ...) [Full GC 217123K->215866K(261888K), 5.5263608 secs] [GC 217207K->216127K(261888K), 1.4741779 secs] ] [64[GC 218175K->216477K(261888K), 0.0265551 secs] [GC 218525K->216896K(261888K), 0.0246568 secs] [GC 218944K->217318K(261888K), 0.0252940 secs] ][GC 219366K->217700K(261888K), 0.0236608 secs] [65[GC 219748K->218130K(261888K), 0.0244581 secs] [GC 220178K->218552K(261888K), 0.0248638 secs] [GC 220600K->218971K(261888K), 0.0303567 secs] ] [66[GC 221019K->219361K(261888K), 0.0230088 secs] ] Parsing of document complete, stopping renderer Initial heap size: 40908Kb Current heap size: 219991Kb Total memory used: 179083Kb Memory use is indicative; no GC was performed These figures should not be used comparatively Total time used: 66075ms Pages rendererd: 66 Avg render time: 1001ms/page > -----Original Message----- > From: J.Pietschmann [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 22, 2003 12:35 PM > To: [EMAIL PROTECTED] > Subject: Re: Big/Huge XMLs > > > Savino, Matt C wrote: > > We increased our max PDF size on this report from 30 pages to 200 > > Huh? What complications do you add to the layout to run out of > memory at only *30* pages? I never had any problems until I got > well past 1000 pages (using -mx128M, JDK 1.3.1) > > J.Pietschmann > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
<<attachment: NAReportOutput.zip>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
