Re: Fop Performance degradation after upgrading from jdk 6 u18 to u19

[Alexios Giotis]

Medhi and Glenn thanks for your quick replies and especially for immediately 
taking care of this. I investigated it a little further by creating a proof of 
concept font caching implementation so that we can measure the benefits. After 
this, it does not seem to me like too much work - it could be roughly a couple 
of days. Our primary target here was to improve FOP performance when used as a 
service in a multi-threaded application and not to externalize and decouple the 
font subsystem from FOP's layout system (although some improvements could be 
included). 

So, here are a few numbers to share. Using a single thread, after a good warm 
up of about 200 FOP executions (XSL:FO to PDF with TTF embedding), the time to 
load arial.ttf or arialb.ttf  gets about 5ms on a 2.66GHz Intel Core 2 Duo 
(from about 250ms the first time) on JDK_1.6.0_31 (FOP trunk). In our use 
cases, the frequently requested transformations are for documents having 4-10 
pages and about 10 different fonts. The execution time for 4-10 pages (and the 
given complexity of layout) is 400-900ms. Font caching would save us about 50ms 
per execution, which is a 5.5%-12.5% improvement. For this use case (which I 
guess is not popular among FOP users) font caching is a marginally interesting 
improvement. If the use cases or those estimations change for some reason, I 
will open a new issue, work on properly implementing this and attach a patch.

Alex Giotis




On Apr 24, 2012, at 10:06 AM, mehdi houshmand wrote:

> No, as far as I know font caching isn't really on anyone's agenda. If someone 
> wanted to do this properly it would be a significant amount of work. The 
> fonts system would have to be externalized so that it behaved more like a 
> font provision service rather than the tight coupling to FOPs layout system. 
> This would mean a lot of code redesign and that's no small feat.


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

Re: Fop Performance degradation after upgrading from jdk 6 u18 to u19

[Αναστάσιος Χαρούλης]

Thank you for your quick replies.

There is a filed bug :

https://issues.apache.org/bugzilla/show_bug.cgi?id=53148

The problem is resolved.

Στις 24 Απριλίου 2012 10:06 π.μ., ο χρήστης mehdi houshmand <
med1...@gmail.com> έγραψε:

> Hi,
>
> I'll address your concerns inline:
>
> 2012/4/24 Αναστάσιος Χαρούλης 
>
>> Hello,
>>
>> We are using Apache FOP 1.0 to create Postscript documents from xml files. 
>> After upgrading the Java Virtual Machine from 1.6 update 18 to 1.6 update 
>> 19, we noticed important performance degradation. The FOP execution time was 
>> increased about 25% - 35% (depends on the number of executions). After 
>> investigating this, we concluded that the code that was responsible for this 
>> delay was in the method setValue of inner class BeanSetter of class 
>> o.a.f.fonts.type1.AFPParser. This method uses reflection to set the value of 
>> a bean and our tests showed that the time to execute a reflection call like 
>> this was increased in jdk6 u19. We also noticed that for each FOP execution 
>> (instantiation of a org.apache.fop.apps.Fop object) the fonts are loaded in 
>> memory (field org.apache.fop.fonts.FontInfo in class AreaTreeHandler) .
>>
>>
> I think you mean o.a.f.fonts.type1.AFMParser (very different to an AFP
> parser) but yes, that mechanism could work just without the use of beans,
> but it's a fickle mechanism and it would have to be done with care.
>
> We are wondering if there is a plan for caching the loaded fonts in an object 
> that is reused between successive executions (e.g. in the  
> org.apache.fop.apps.FopFactory). This would mean that the extra cost would 
> occur only in the first execution. Do you think this is a good idea or is 
> there a specific reason for the fonts not to be cached ?
>>
>> No, as far as I know font caching isn't really on anyone's agenda. If
> someone wanted to do this properly it would be a significant amount of
> work. The fonts system would have to be externalized so that it behaved
> more like a font provision service rather than the tight coupling to FOPs
> layout system. This would mean a lot of code redesign and that's no small
> feat.
>
> If the fonts caching is not a good idea, do you think the use of reflection 
> in the BeanSetter class could be avoided?
>>
>> Font caching is a good idea, it's just a lot of work... And I do think
> the BeanSetter could be avoided, but the current code is battle-hardened so
> you'd just have to make sure you test it thoroughly to avoid regressions. I
> wanted remove the BeanSetter system when working in that initially, but as
> always more pressing concerns took over.
>
> 
>
> Hope that helps,
>
> Mehdi
>

Re: Fop Performance degradation after upgrading from jdk 6 u18 to u19

[mehdi houshmand]

Hi,

I'll address your concerns inline:

2012/4/24 Αναστάσιος Χαρούλης 

> Hello,
>
> We are using Apache FOP 1.0 to create Postscript documents from xml files. 
> After upgrading the Java Virtual Machine from 1.6 update 18 to 1.6 update 19, 
> we noticed important performance degradation. The FOP execution time was 
> increased about 25% - 35% (depends on the number of executions). After 
> investigating this, we concluded that the code that was responsible for this 
> delay was in the method setValue of inner class BeanSetter of class 
> o.a.f.fonts.type1.AFPParser. This method uses reflection to set the value of 
> a bean and our tests showed that the time to execute a reflection call like 
> this was increased in jdk6 u19. We also noticed that for each FOP execution 
> (instantiation of a org.apache.fop.apps.Fop object) the fonts are loaded in 
> memory (field org.apache.fop.fonts.FontInfo in class AreaTreeHandler) .
>
>
I think you mean o.a.f.fonts.type1.AFMParser (very different to an AFP
parser) but yes, that mechanism could work just without the use of beans,
but it's a fickle mechanism and it would have to be done with care.

We are wondering if there is a plan for caching the loaded fonts in an
object that is reused between successive executions (e.g. in the
org.apache.fop.apps.FopFactory). This would mean that the extra cost
would occur only in the first execution. Do you think this is a good
idea or is there a specific reason for the fonts not to be cached ?
>
> No, as far as I know font caching isn't really on anyone's agenda. If
someone wanted to do this properly it would be a significant amount of
work. The fonts system would have to be externalized so that it behaved
more like a font provision service rather than the tight coupling to FOPs
layout system. This would mean a lot of code redesign and that's no small
feat.

If the fonts caching is not a good idea, do you think the use of
reflection in the BeanSetter class could be avoided?
>
> Font caching is a good idea, it's just a lot of work... And I do think the
BeanSetter could be avoided, but the current code is battle-hardened so
you'd just have to make sure you test it thoroughly to avoid regressions. I
wanted remove the BeanSetter system when working in that initially, but as
always more pressing concerns took over.



Hope that helps,

Mehdi

Re: Fop Performance degradation after upgrading from jdk 6 u18 to u19

[Glenn Adams]

please file one ore more bugs at [1], product "Fop", and please ensure the
following are attached to each bug:

   - a "maximally minimal" input FO files that demonstrates problem
   - an output file (PDF, AFP, etc.,) relevant to running your input file
   - console log output
   - version information (fop version, jdk version, etc)

also, you may wish to review the problem reported at [2] to see if it is
relevant to what you are seeing

[1] https://issues.apache.org/bugzilla/enter_bug.cgi
[2] https://issues.apache.org/bugzilla/show_bug.cgi?id=51149

regarding plans to cache loaded fonts between successive reuses of an
FopFactory instance, there aren't any as far as I'm aware; so if you wish,
you can file a bug on this with severity "enhancement"

as an fyi, one way to reduce font load time is to configure fop to only
load the fonts you need, i.e., don't use  and limit the fonts
listed in the config file to those you use; this is just a possible
workaround though, to reduce the impact you are encountering

2012/4/24 Αναστάσιος Χαρούλης 

> Hello,
>
> We are using Apache FOP 1.0 to create Postscript documents from xml files. 
> After upgrading the Java Virtual Machine from 1.6 update 18 to 1.6 update 19, 
> we noticed important performance degradation. The FOP execution time was 
> increased about 25% - 35% (depends on the number of executions). After 
> investigating this, we concluded that the code that was responsible for this 
> delay was in the method setValue of inner class BeanSetter of class 
> o.a.f.fonts.type1.AFPParser. This method uses reflection to set the value of 
> a bean and our tests showed that the time to execute a reflection call like 
> this was increased in jdk6 u19. We also noticed that for each FOP execution 
> (instantiation of a org.apache.fop.apps.Fop object) the fonts are loaded in 
> memory (field org.apache.fop.fonts.FontInfo in class AreaTreeHandler) .
>
>
> We are wondering if there is a plan for caching the loaded fonts in an object 
> that is reused between successive executions (e.g. in the  
> org.apache.fop.apps.FopFactory). This would mean that the extra cost would 
> occur only in the first execution. Do you think this is a good idea or is 
> there a specific reason for the fonts not to be cached ?
>
>
> If the fonts caching is not a good idea, do you think the use of reflection 
> in the BeanSetter class could be avoided?
>
>
> Attached you may find a sample application that demonstrates the issue. This 
> application instantiates Fop and executes a conversion 200 times. The class 
> file is foptest.FopTest. Libraries of FOP should exist in the classpath.
>
>
> (Execute java -cp ... foptest.FopTest in  the extracted folder)
>
> Also in the class foptest.ReflectionTest it is demonstrated the mentioned 
> problem with the reflection call.
>
> Note: There is no (noticed) performance degradation if only one conversion 
> runs.
>
> Thanks in advance,
>
> Tassos
>
>
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>

RE: Fop performance

[David Morales de Frias]

Try to use cached stylesheets... it can improve performance.

 

http://www.topxml.com/xsl/articles/java_xslt/default.asp

 

See at bottom.

 



From: Jason Timmins [mailto:[EMAIL PROTECTED] 
Sent: viernes, 29 de junio de 2007 11:58
To: fop-users@xmlgraphics.apache.org
Subject: RE: Fop performance

 

Hi There,

 

I had much the same problem myself. I needed to create PDFs quickly for
the web but also Postscript for high-volume laser printers. It was
taking seven seconds to run Saxon, run FOP and get the PDF/PS. This was
way too slow for my application.

 

To be fair, FOP is pretty quick, the slow part seems to be the
initialisation of the JavaVM (which I was doing once for Saxon and again
for FOP.) I'm in the .NET environment so I gave up on Saxon and switch
to a .NET implementation. I also used IKVM to translate FOP (0.20.X)
into a .NET component so that now Windows doesn't have to use the JavaVM
and all the code runs in the same IIS execution environment.

 

The result of all this effort was that the generation time dropped from
seven seconds to two seconds.

 

I'd like to use the native Java version of FOP but how can I make it run
really quickly for lots of small PDFs?

 

Bye for now

Jason.

 

Jason Timmins (Technical Director) InterLinx
<http://www.interlinx.co.uk/>  Ltd.

 Geo: West Mids, UK
<http://www.multimap.com/map/browse.cgi?lat=52.5363&lon=-2.1866&scale=10
000&icon=x> . Tele: +44 8707 430999. Fax: +44 8707 460999.

Beyond here there be dragons!

 

From: Laurent Berthelot [mailto:[EMAIL PROTECTED] 
Sent: 29 June 2007 06:57
To: fop-users@xmlgraphics.apache.org
Subject: Fop performance

 

Hello,

 

I try to optimize FOP performance.

I make litlle dynamical PDF (2 pages) on the fly for a web site, and i
need several second to generate PDF.
FOP need a lot of CPU...

 

Have you the same problem ?

 

Regards,

 

Laurent Berthelot



This email has been scanned for all viruses by the InterLinx Anti-Virus
Email service. For more information on a proactive anti-virus service
working around the clock, around the globe, visit
http://www.interlinx.co.uk/anti-virus-anti-spam.htm



--
This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be privileged. If you receive this e-mail
in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group
liability cannot be triggered for the message content. Although the
sender endeavours to maintain a computer virus-free network, the sender does
not warrant that this transmission is virus-free and will not be liable for
any damages resulting from any virus transmitted.

Este mensaje y los ficheros adjuntos pueden contener informacion
confidencial destinada solamente a la(s) persona(s) mencionadas
anteriormente. Pueden estar protegidos por secreto profesional Si usted
recibe este correo electronico por error, gracias de informar inmediatamente
al remitente y destruir el mensaje.
Al no estar asegurada la integridad de este mensaje sobre la red, Atos
Origin no se hace responsable por su contenido. Su contenido no constituye
ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita por
ambas partes.
Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor
no puede garantizar nada al respecto y no sera responsable de cualesquiera
danos que puedan resultar de una transmision de virus
--

Re: Fop performance

[Jeremias Maerki]

On 29.06.2007 11:57:37 Jason Timmins wrote:

> I'd like to use the native Java version of FOP but how can I make it run
> really quickly for lots of small PDFs?


You can deploy FOP as a WebService or as a servlet in an application
server.

I once did a proof-of-concept implementation where I deployed FOP in a
WebService in a Jetty container. I started the JVM from inside a Delphi
application in-process (using JNI) and then called the WebService using
Delphi's WebService facilities. I did this to deploy FOP in a client
application. Shouldn't be too hard to do something similar in a .NET
environment. But you seem to be in a server environment, so it's easier
to just install Tomcat as a Windows Service and deploy FOP in it. That
should give you the response times you want. The servlet variant is
probably easier to implement if the requirements allow it.

Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Fop performance

[Jason Timmins]

Hi There,

 

I had much the same problem myself. I needed to create PDFs quickly for the
web but also Postscript for high-volume laser printers. It was taking seven
seconds to run Saxon, run FOP and get the PDF/PS. This was way too slow for
my application.

 

To be fair, FOP is pretty quick, the slow part seems to be the
initialisation of the JavaVM (which I was doing once for Saxon and again for
FOP.) I'm in the .NET environment so I gave up on Saxon and switch to a .NET
implementation. I also used IKVM to translate FOP (0.20.X) into a .NET
component so that now Windows doesn't have to use the JavaVM and all the
code runs in the same IIS execution environment.

 

The result of all this effort was that the generation time dropped from
seven seconds to two seconds.

 

I'd like to use the native Java version of FOP but how can I make it run
really quickly for lots of small PDFs?

 

Bye for now

Jason.

 

Jason Timmins (Technical Director) InterLinx 
Ltd.

 Geo:
  West Mids, UK. Tele: +44 8707 430999. Fax: +44 8707 460999.

Beyond here there be dragons!

 

From: Laurent Berthelot [mailto:[EMAIL PROTECTED] 
Sent: 29 June 2007 06:57
To: fop-users@xmlgraphics.apache.org
Subject: Fop performance

 

Hello,

 

I try to optimize FOP performance.

I make litlle dynamical PDF (2 pages) on the fly for a web site, and i need
several second to generate PDF.
FOP need a lot of CPU...

 

Have you the same problem ?

 

Regards,

 

Laurent Berthelot




This email has been scanned for all viruses by the InterLinx Anti-Virus
Email service. For more information on a proactive anti-virus service
working around the clock, around the globe, visit
http://www.interlinx.co.uk/anti-virus-anti-spam.htm

Re: FOP performance issue

[Jeremias Maerki]

I've seen a similar behaviour back in my FOP 0.20.5 times. But in the
end I concatenated the documents on the PostScript level, not on the FO
level.

However, if your stack trace is any indicator, the problem is inside
Xalan-J (no FOP classes involved in the stack trace). Maybe it has to
build up all these subtrees internally plus you see the effect of
excessive garbage collection. FOP 0.92beta is certainly not a memory
saver, yet, since there have not been any larger optimization efforts,
so FOP could also be involved.

I'd do the following: Concatenate your documents separately and
serialize the resulting FO to a file and then fill that file into FOP.
Check if there's any difference in behaviour. It may help you to
identify if it's Xalan-J or FOP which is the larger problem spot.

As an alternative to XSL-FO concatenation I can recommend to you look at
FOP's intermediate format. Using the "IF" you can render each single
document separately to an XML file which you can finally render to the
target format at which point you can do the concatenation by supplying
multiple IF files. This is described in [1] with an example in [2].
Could be an alternative.

[1] http://xmlgraphics.apache.org/fop/latest/intermediate.html
[2] 
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/ExampleConcat.java

On 21.06.2006 07:24:46 Karthik wrote:
> 
> Hi all,
> 
> We are currently running FOP in a batch environment on Websphere 5.1.
> Are experiencing a performance lag while processing higher volume of 
> documents. 
> A brief explanation of the process : 'n' number of XML's are concatenated 
> into 1 PDF  file. I use page-sequencing to create the output PDF. 
> Whats happening is that the larger the 'n', the process becomes very slower. 
> For e.g, for 200 xml's the PDF was created in approx 4 minutes, but, 
> if I increased it to 500, it almost took an hour to create the PDF. I took 
> threaddumps and I found that the process stalls at a certain method call -
> org.apache.xml.dtm.ref.DTMDefaultBaseTraversers$DescendantTraverser.next
> (DTMDefaultBaseTraversers.java(Compiled Code)). 
> Below is the relevant portion of the dump:
> 3XMTHREADINFO  "MessageListenerThreadPool : 1" (TID:0x1061D250,
> sys_thread_t:0x53985C38, state:R, 
> native ID:0x1324) prio=5
> 4XESTACKTRACE  at
> org.apache.xml.dtm.ref.DTMDefaultBaseTraversers$DescendantTraverser.next
> (DTMDefaultBaseTraversers.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xpath.axes.AxesWalker.getNextNode(AxesWalker.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xpath.axes.AxesWalker.nextNode(AxesWalker.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xpath.axes.WalkingIterator.nextNode
> (WalkingIterator.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xpath.axes.NodeSequence.nextNode(NodeSequence.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xpath.axes.NodeSequence.runTo(NodeSequence.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xpath.axes.NodeSequence.setRoot(NodeSequence.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xpath.axes.LocPathIterator.execute(LocPathIterator.java
> (Compiled Code))
> 4XESTACKTRACE   at 
> org.apache.xpath.objects.XRTreeFragSelectWrapper.execute
> (XRTreeFragSelectWrapper.java(Compiled Code))
> 4XESTACKTRACE  at org.apache.xpath.XPath.execute(XPath.java(Compiled 
> Code))
> 4XESTACKTRACE  at
> org.apache.xalan.templates.ElemWithParam.getValue(ElemWithParam.java
> (Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java
> (CompiledCode))
> 4XESTACKTRACE  at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates
> (TransformerImpl.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates
> (TransformerImpl.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java
> (Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java
> (CompiledCode))
> 4XESTACKTRACE  at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates
> (TransformerImpl.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xalan.templates.ElemChoose.execute(ElemChoose.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates
> (TransformerImpl.java(Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xalan.templates.ElemTemplate.execute(ElemTemplate.java
> (Compiled Code))
> 4XESTACKTRACE  at
> org.apache.xalan.templates.ElemCallTemplate.execute(ElemCallTemplate.java
> (CompiledCode))
> 4XESTACKTRACE  at
> org.apache.xalan.transform

RE: FOP Performance

[Michael Dabney]

Yeah, this is definitely 0.20.5 specific.

On Nov 11, 2005, at 21:11, Michael Dabney wrote:

Hi Michael,

> I have done just that: http://wiki.apache.org/xmlgraphics-fop/HowTo/ 
> PHPJavaBridge
>
> I linked to it on the front page as well.

Thanks a lot for taking the time to do this!

May need some minor tweaks to make it relevant for FOP Trunk, which  
will be released next week, but just wanted to let you know that your  
contribution is much appreciated.


Cheers,

Andreas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


<>-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOP Performance

[Andreas L Delmelle]

On Nov 11, 2005, at 21:11, Michael Dabney wrote:

Hi Michael,

I have done just that: http://wiki.apache.org/xmlgraphics-fop/HowTo/ 
PHPJavaBridge


I linked to it on the front page as well.


Thanks a lot for taking the time to do this!

May need some minor tweaks to make it relevant for FOP Trunk, which  
will be released next week, but just wanted to let you know that your  
contribution is much appreciated.



Cheers,

Andreas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: FOP Performance

[Michael Dabney]

I have done just that: 
http://wiki.apache.org/xmlgraphics-fop/HowTo/PHPJavaBridge

I linked to it on the front page as well.

-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Fri 11/11/2005 5:04 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP Performance
 
http://xmlgraphics.apache.org/fop/0.20.5/servlets.html

Basically you need to:
- build the sample FOP servlet as described on the above page
- Download Apache Tomcat and install it as a service
- Deploy FOP in Tomcat as described on the above page

I know almost nothing about PHP so I wouldn't know about any better
approaches to this from the PHP point of view. Maybe you can Michael
Dabney to publish the details of his solution using the PHP Java Bridge
on the FOP Wiki [1] under the "HowTo" section. His approach sounds
pretty good, too.

[1] http://wiki.apache.org/xmlgraphics-fop/


On 11.11.2005 11:50:23 Christian Loock wrote:
> I'm not very fit in all this technical stuff. Do you know any kind of
> documentation etc. which could help me keeping FOP in memory?
> 
> Best Regards,
> 
> Christian
> 
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 11, 2005 11:26 AM
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: FOP Performance
> 
> Batik takes a long time to warm up due to its size (class loading). If
> you use the servlet approach, i.e. having FOP up, running and ready the
> whole time, it will speed up the process a lot. If you find another way
> to hold FOP and the VM it runs in memory over multiple rendering
> runs(some PHP extension, a web service or whatever), that's fine, too.
> Most of the time is simply lost with class loading and initialization.
> HTH.
> 
> On 11.11.2005 10:59:45 Christian Loock wrote:
> > Hi again!
> > 
> > The Performance problem figured out to be a problem in using SVG 
> > images as Backgorund images for the xsl-region-before/after/start/end.
> > 
> > Any ideas on how to fix this problem without changing to another 
> > picture format. (jpg and gif do look bad imho)
> 
> 
> Jeremias Maerki
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


<>-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOP Performance

[Jeremias Maerki]

http://xmlgraphics.apache.org/fop/0.20.5/servlets.html

Basically you need to:
- build the sample FOP servlet as described on the above page
- Download Apache Tomcat and install it as a service
- Deploy FOP in Tomcat as described on the above page

I know almost nothing about PHP so I wouldn't know about any better
approaches to this from the PHP point of view. Maybe you can Michael
Dabney to publish the details of his solution using the PHP Java Bridge
on the FOP Wiki [1] under the "HowTo" section. His approach sounds
pretty good, too.

[1] http://wiki.apache.org/xmlgraphics-fop/


On 11.11.2005 11:50:23 Christian Loock wrote:
> I'm not very fit in all this technical stuff. Do you know any kind of
> documentation etc. which could help me keeping FOP in memory?
> 
> Best Regards,
> 
> Christian
> 
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 11, 2005 11:26 AM
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: FOP Performance
> 
> Batik takes a long time to warm up due to its size (class loading). If
> you use the servlet approach, i.e. having FOP up, running and ready the
> whole time, it will speed up the process a lot. If you find another way
> to hold FOP and the VM it runs in memory over multiple rendering
> runs(some PHP extension, a web service or whatever), that's fine, too.
> Most of the time is simply lost with class loading and initialization.
> HTH.
> 
> On 11.11.2005 10:59:45 Christian Loock wrote:
> > Hi again!
> > 
> > The Performance problem figured out to be a problem in using SVG 
> > images as Backgorund images for the xsl-region-before/after/start/end.
> > 
> > Any ideas on how to fix this problem without changing to another 
> > picture format. (jpg and gif do look bad imho)
> 
> 
> Jeremias Maerki
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: FOP Performance

[Christian Loock]

I'm not very fit in all this technical stuff. Do you know any kind of
documentation etc. which could help me keeping FOP in memory?

Best Regards,

Christian

-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 11, 2005 11:26 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP Performance

Batik takes a long time to warm up due to its size (class loading). If
you use the servlet approach, i.e. having FOP up, running and ready the
whole time, it will speed up the process a lot. If you find another way
to hold FOP and the VM it runs in memory over multiple rendering
runs(some PHP extension, a web service or whatever), that's fine, too.
Most of the time is simply lost with class loading and initialization.
HTH.

On 11.11.2005 10:59:45 Christian Loock wrote:
> Hi again!
> 
> The Performance problem figured out to be a problem in using SVG 
> images as Backgorund images for the xsl-region-before/after/start/end.
> 
> Any ideas on how to fix this problem without changing to another 
> picture format. (jpg and gif do look bad imho)


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOP Performance

[Jeremias Maerki]

Batik takes a long time to warm up due to its size (class loading). If
you use the servlet approach, i.e. having FOP up, running and ready the
whole time, it will speed up the process a lot. If you find another way
to hold FOP and the VM it runs in memory over multiple rendering
runs(some PHP extension, a web service or whatever), that's fine, too.
Most of the time is simply lost with class loading and initialization.
HTH.

On 11.11.2005 10:59:45 Christian Loock wrote:
> Hi again!
> 
> The Performance problem figured out to be a problem in using SVG images
> as Backgorund images for the xsl-region-before/after/start/end.
> 
> Any ideas on how to fix this problem without changing to another picture
> format. (jpg and gif do look bad imho)


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: FOP Performance

[Christian Loock]

Hi again!

The Performance problem figured out to be a problem in using SVG images
as Backgorund images for the xsl-region-before/after/start/end.

Any ideas on how to fix this problem without changing to another picture
format. (jpg and gif do look bad imho)

Thanks and best regards,

Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOP Performance

[Matthew L Daniel]

> Yes we use PHP? Why?

FWIW, we also have an intranet PDF solution with embedded FOP, but we
are using an architecture based on how FopServlet does it. We are
consistently getting render times around 8s for a 4-5 page PDF using
InputStreams (in contrast to Files, as FopServlet does it).

I am not trying to migrate your app off php, but I would encourage you
to at least try a FopServlet based solution and see if it meets your
needs.

  My USD$0.02,
  -- /v\atthew

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOP Performance

[Andreas L Delmelle]

On Nov 10, 2005, at 14:22, Christian Loock wrote:

Hi,


I've set up an application using FOP 0.20.5 to generate dynamic PDF
Contents...

Using it on our development Server works very finde and fast but the
same app on an other Server seems to be much slower...


Well, for starters: development servers usually are much less heavily  
loaded, which could explain why the same process runs much faster on  
the first.


Are you absolutely certain that the workload on both servers is equal  
(or comparable)? If your development server has 10 other processes  
running at the same time, and your production server has a 100 other  
processes running, then it should be clear that one can't expect both  
machines to perform the rendering in the same amount of time (unless  
the production server is much more powerful)


What order of magnitude are you talking about (Two, three or twenty  
times slower)? Have you performed any measurements?



HTH!

Greetz,

Andreas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOP Performance

[Jimmy Dixon]

Hi Christian

What scripting language are you using? Not PHP by any chance?

Thanks.
Jimmy.

Christian Loock wrote:


Hi Everybody,

I've set up an application using FOP 0.20.5 to generate dynamic PDF
Contents...

Using it on our development Server works very finde and fast but the
same app on an other Server seems to be much slower...

What I'd like to know are things which are important for the Server that
FOP can run fast as it does on our dev Server.

Best Regard,

Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 



--
Jimmy Dixon, Perfiliate Technologies

email   :  [EMAIL PROTECTED]
phone   :  +44 (0)191 241 6500

Registered Office:
Perfiliate Technologies Limited
7-15 Pink Lane,
Newcastle upon Tyne. NE1 5DW
Registered No. 3783384 in the UK

Telephone +44 (0)191 241 6500
Facsimile +44 (0)191 241 9302

www.perfiliate.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful. We check all emails for viruses, but please 
note that we do not accept liability for any viruses which may be transmitted 
in or with this email.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOP Performance

[Dirk Bromberg]

Hi,

is there a different Hardware? Or is the java version (memorysettings) 
different?


Thanks

Dirk

Christian Loock wrote:

Hi Everybody,

I've set up an application using FOP 0.20.5 to generate dynamic PDF
Contents...

Using it on our development Server works very finde and fast but the
same app on an other Server seems to be much slower...

What I'd like to know are things which are important for the Server that
FOP can run fast as it does on our dev Server.

Best Regard,

Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]