You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by "Tobias Anstett [k15t.com]" <to...@k15t.com> on 2009/05/05 17:41:39 UTC

Performance of Apache FOP

Hi,

We are using Apache FOP inside a web-app deployed within Apache
Tomcat. When the FO documents get to big (~20MB) we are getting out of
memory exceptions (java heap space overflows) while transforming FO to
PDF. We already assigned more than 1024m to the JVM but still get not
rid of this problem.

I already checked the
http://xmlgraphics.apache.org/fop/0.94/embedding.html#performance
documentation but it seams that we did everything like suggested. Any
ideas?

Cheers,
Tobias

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by Artur Zinatullin <ar...@webmedia.ee>.
 ??>> Currently (with another library) I am flushing out
 ??>> every 200 rows and all the thing (800 pages totally) builds in a
 ??>> matter of seconds.
 TAk> Which library are you referring to ?
Actually, it's about scalability.
I've got 99% cases, where table is no bigger than 100 rows.
Everything worked perfectly, untill two cases with 10k+ rows
appeared. Now I'm building the title page and 3 tables with
FO and 2 tables (simple in layout, but bulky data) with iText.
Then concatenate into single document.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by Artur Zinatullin <ar...@webmedia.ee>.
 ??>> Currently (with another library) I am flushing out
 ??>> every 200 rows and all the thing (800 pages totally) builds in a
 ??>> matter of seconds.
 TAk> Which library are you referring to ?
iText

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by "Tobias Anstett [k15t.com]" <to...@k15t.com>.
> Currently (with another library) I am flushing out
> every 200 rows and all the thing (800 pages totally) builds in a matter
> of seconds.

Which library are you referring to ?

- Tobias -

On Tue, May 5, 2009 at 6:57 PM, Artur Zinatullin <ar...@webmedia.ee> wrote:
>
> AC> In your case not, but in many cases using many page sequences
> AC> to break up the FO content can help a great deal.
> I beleave that indeed.
> If FO was able to flush out page by page, for instance, there woud
> be no problem. Currently (with another library) I am flushing out
> every 200 rows and all the thing (800 pages totally) builds in a matter
> of seconds. I had to wait 10+ minutes before my previous solution
> (with FOP) crashed the server :)
>
> AC> In your situation you would indeed have to take care of pagination
> That's too much pain :)
>
> AC> I would suggest you split up the 17k rows into many tables with the
> AC> same column headings (one per page with x rows of content on each
> AC> page), then use the break-after="page" property to ensure the next
> AC> table starts at the top of the next page.
> Unfortunatelly, the client likes that table continously.
> I have no idea how to achieve that without breking into FO pagination
> mechanism.
> Which I don't want to do for sure :)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by Artur Zinatullin <ar...@webmedia.ee>.
 AC> In your case not, but in many cases using many page sequences
 AC> to break up the FO content can help a great deal.
I beleave that indeed.
If FO was able to flush out page by page, for instance, there woud
be no problem. Currently (with another library) I am flushing out
every 200 rows and all the thing (800 pages totally) builds in a matter
of seconds. I had to wait 10+ minutes before my previous solution
(with FOP) crashed the server :)

 AC> In your situation you would indeed have to take care of pagination
That's too much pain :)

 AC> I would suggest you split up the 17k rows into many tables with the
 AC> same column headings (one per page with x rows of content on each
 AC> page), then use the break-after="page" property to ensure the next
 AC> table starts at the top of the next page.
Unfortunatelly, the client likes that table continously.
I have no idea how to achieve that without breking into FO pagination 
mechanism.
Which I don't want to do for sure :)


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by "Tobias Anstett [k15t.com]" <to...@k15t.com>.
Hi,

I am using the DocBook XSL Stylesheets to generate FO. So the best way
to solve my memory issue would be to diverge from article style and
start a new fo:page-sequence after every major section like I would do
in book style for chapters...

Thanks for all the help ;)

Cheers,
Tobias

On Tue, May 5, 2009 at 8:30 PM, Andreas Delmelle
<an...@telenet.be> wrote:
> On 05 May 2009, at 18:47, Tobias Anstett [k15t.com] wrote:
>
> Hi Tobias
>
>> does a fo:page-sequence always "break a page" or is there a way to
>> continue on the same page?
>
> Yes, a new page-sequence always starts on a new page. No way to disable
> this.
> Note that using forced breaks (break-before/break-after) inside a
> page-sequence only saves in the layout process, while starting a new
> page-sequence also releases all objects related to the FO tree.
>
>
> Regards
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by Andreas Delmelle <an...@telenet.be>.
On 05 May 2009, at 18:47, Tobias Anstett [k15t.com] wrote:

Hi Tobias

> does a fo:page-sequence always "break a page" or is there a way to
> continue on the same page?

Yes, a new page-sequence always starts on a new page. No way to  
disable this.
Note that using forced breaks (break-before/break-after) inside a page- 
sequence only saves in the layout process, while starting a new page- 
sequence also releases all objects related to the FO tree.


Regards

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by "Tobias Anstett [k15t.com]" <to...@k15t.com>.
Hi Adrian,

does a fo:page-sequence always "break a page" or is there a way to
continue on the same page?

Cheers,
Tobias

On Tue, May 5, 2009 at 6:44 PM, Adrian Cumiskey <de...@cumiskey.com> wrote:
> Hi Artur,
>
> In your case not, but in many cases using many page sequences to break up
> the FO content can help a great deal.
>
> In your situation you would indeed have to take care of pagination, I would
> suggest you split up the 17k rows into many tables with the same column
> headings (one per page with x rows of content on each page), then use the
> break-after="page" property to ensure the next table starts at the top of
> the next page.
>
> Adrian.
>
> Artur Zinatullin wrote:
>>
>> AC> Do you use many page sequences in your FO documents?  FOP processes
>> AC> documents by page sequence so if you can section the document contents
>> AC> into lots of small page sequence segments this can help a lot with
>> AC> memory consumption.
>> I have just dealt with the problem.
>> The table with 17k rows x 12 cells brought the server to it's knees.
>> If I knew, that I can use multiple page sequences... woud it help me?
>> I mean, that theese rows were not of fixed height. If I used multiple
>> page sequences to print one continous table, woud I have to do pagination
>> manually?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by Adrian Cumiskey <de...@cumiskey.com>.
Hi Artur,

In your case not, but in many cases using many page sequences to break 
up the FO content can help a great deal.

In your situation you would indeed have to take care of pagination, I 
would suggest you split up the 17k rows into many tables with the same 
column headings (one per page with x rows of content on each page), then 
use the break-after="page" property to ensure the next table starts at 
the top of the next page.

Adrian.

Artur Zinatullin wrote:
>
> AC> Do you use many page sequences in your FO documents?  FOP processes
> AC> documents by page sequence so if you can section the document 
> contents
> AC> into lots of small page sequence segments this can help a lot with
> AC> memory consumption.
> I have just dealt with the problem.
> The table with 17k rows x 12 cells brought the server to it's knees.
> If I knew, that I can use multiple page sequences... woud it help me?
> I mean, that theese rows were not of fixed height. If I used multiple
> page sequences to print one continous table, woud I have to do pagination
> manually?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by "Tobias Anstett [k15t.com]" <to...@k15t.com>.
Hi Artur,

In my opinion you will have to deal with pagination manually. The
problem is like you described the variable height of the table rows.
So you can e.g. split after each 500 rows or something like that. Thus
there shouldn't be a out of memory exception (hopefully) but you table
may end within a page and continued on a new page.

Maybe there is a paramter like "suppress page sequence breaks" - but I
am not aware of it...

Cheers,
Tobias


On Tue, May 5, 2009 at 6:15 PM, Artur Zinatullin <ar...@webmedia.ee> wrote:
>
> AC> Do you use many page sequences in your FO documents?  FOP processes
> AC> documents by page sequence so if you can section the document contents
> AC> into lots of small page sequence segments this can help a lot with
> AC> memory consumption.
> I have just dealt with the problem.
> The table with 17k rows x 12 cells brought the server to it's knees.
> If I knew, that I can use multiple page sequences... woud it help me?
> I mean, that theese rows were not of fixed height. If I used multiple
> page sequences to print one continous table, woud I have to do pagination
> manually?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by Artur Zinatullin <ar...@webmedia.ee>.
 AC> Do you use many page sequences in your FO documents?  FOP processes
 AC> documents by page sequence so if you can section the document contents
 AC> into lots of small page sequence segments this can help a lot with
 AC> memory consumption.
I have just dealt with the problem.
The table with 17k rows x 12 cells brought the server to it's knees.
If I knew, that I can use multiple page sequences... woud it help me?
I mean, that theese rows were not of fixed height. If I used multiple
page sequences to print one continous table, woud I have to do pagination
manually? 


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by "Tobias Anstett [k15t.com]" <to...@k15t.com>.
Hi Adrian,

yes, seams like the whole content is wrapped in one big
fo:page-sequence. So there is room for improvement :)

I will write to the DocBook XSL mailinglist to get some tip how I can
split it in more fine grained fo:page-sequence junks.

Cheers and thanks,
Tobias

On Tue, May 5, 2009 at 5:56 PM, Adrian Cumiskey <de...@cumiskey.com> wrote:
> Hi Tobias,
>
> Do you use many page sequences in your FO documents?  FOP processes
> documents by page sequence so if you can section the document contents into
> lots of small page sequence segments this can help a lot with memory
> consumption.
>
> Good luck!
>
> Adrian.
>
> Tobias Anstett [k15t.com] wrote:
>>
>> Hi,
>>
>> We are using Apache FOP inside a web-app deployed within Apache
>> Tomcat. When the FO documents get to big (~20MB) we are getting out of
>> memory exceptions (java heap space overflows) while transforming FO to
>> PDF. We already assigned more than 1024m to the JVM but still get not
>> rid of this problem.
>>
>> I already checked the
>> http://xmlgraphics.apache.org/fop/0.94/embedding.html#performance
>> documentation but it seams that we did everything like suggested. Any
>> ideas?
>>
>> Cheers,
>> Tobias
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Performance of Apache FOP

Posted by Adrian Cumiskey <de...@cumiskey.com>.
Hi Tobias,

Do you use many page sequences in your FO documents?  FOP processes 
documents by page sequence so if you can section the document contents 
into lots of small page sequence segments this can help a lot with 
memory consumption.

Good luck!

Adrian.

Tobias Anstett [k15t.com] wrote:
> Hi,
>
> We are using Apache FOP inside a web-app deployed within Apache
> Tomcat. When the FO documents get to big (~20MB) we are getting out of
> memory exceptions (java heap space overflows) while transforming FO to
> PDF. We already assigned more than 1024m to the JVM but still get not
> rid of this problem.
>
> I already checked the
> http://xmlgraphics.apache.org/fop/0.94/embedding.html#performance
> documentation but it seams that we did everything like suggested. Any
> ideas?
>
> Cheers,
> Tobias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org