From: Alexander Peshkov (peshkov@renderx.com)
Date: Fri Aug 20 2004 - 00:59:55 PDT
Hello, all.
I'm forwarding slightly abbreviated correspondence with Paul Hosking
regarding XEP performance under Tomcat to the public mailing list so
that it will be stored in the list archive.
Best regards,
Alexander Peshkov mailto:peshkov@renderx.com
RenderX
This is a forwarded message
From: Paul Hosking <paul.hosking@solnetsolutions.co.nz>
To: Alex Peshkov <support@renderx.com>
Date: Thursday, August 19, 2004, 12:51:06 AM
Subject: FW: XEP Performance
===8<==============Original message text===============
Hi Alexander,
That's fine by me. An indication of just how the change in garbage
collector and memory settings affected performance is that for the XSLT
spec example, using the original memory settings and the incremental
garbage collector resulted in the garbage collector being invoked over
1500 times during the rendering of the document. Using the new memory
settings and the default garbage collector, the garbage collector was
invoked only 8 times (and performance was 500% better).
Cheers,
Paul
Alex Peshkov wrote:
>Hello, Paul.
>
>Thanks for update on this issue. May I forward your letter to our
>public mailing list (xep-support@renderx.com)? It would be nice if
>this message will be available in the list archive (in case someone
>else will hit the same problem).
>
>Best regards,
>Alexander Peshkov mailto:peshkov@renderx.com
>RenderX
>
>PH> Hi Alexander,
>
>PH> Thanks for your reply. I had been using a cached version of the
>PH> formatter object, so startup time was not an issue. However, I have
>PH> done some more testing and it appears that the memory settings and
>PH> choice of garbage collector for the JVM that was running Tomcat were
>PH> limiting the performance of the renderer. I bumped up the memory
>PH> settings (from initial 128MB / max 256MB to initial 512MB / max 512MB)
>PH> and switched from using the incremental garbage collector to the default
>PH> garbage collector, and this reduced the processing time for my test
>PH> document from 4+ seconds to 1 second. The processing time for the XSLT
>PH> spec example that Kevin suggested I use reduced from 32 seconds to 6
>PH> seconds. These were all "one off" tests, and I intend to rerun our load
>PH> tests to confirm that scalability will not be a problem, but I am a lot
>PH> more confident now.
>
>PH> Thanks again for your help.
>
>PH> Cheers,
>PH> Paul
>
>PH> Alexander Peshkov wrote:
>
>
>
>>>Hello Paul,
>>>
>>>your message bounced from xep-support list because of attachment. If
>>>you need to send something directly to the support team, please use
>>>the address support@renderx.com.
>>>
>>>4 seconds for a command-line run is OK since it includes Java startup
>>>overhead as well as formatter creation time. However performance
>>>that you cite for embedded XEP is somewhat surprising, I believe it
>>>has something to do with the way you embed XEP into your servlet
>>>container. For example, a common error is a re-creation of the
>>>formatter object for every request - XEP formatter is reusable object
>>>that should be kept persistent since it's creation is a time consuming
>>>operation, in addition every time you create formatter it reads
>>>configuration and fonts files form the disk so that concurrent
>>>creations of many formatter instances can lead to the disk queues.
>>>
>>>As for the test document you send us - there is nothing wrong with it,
>>>our clients use XEP to format documents that are orders of magnitude
>>>larger and have a much more complicated structure. As a general advice
>>>regarding XSL-FO structures and performance I would recommend to avoid
>>>use of the long tables when possible sine tables are the most
>>>"resource hungry" XSL-FO constructs from formatter point of view.
>>>
>>>Best regards,
>>>Alexander Peshkov mailto:peshkov@renderx.com
>>>RenderX
>>>
>>>
>>>
>>>> Paul Hosking <paul.hosking@solnetsolutions.co.nz> 12-Aug-04 11:56:21 p.m.
>>>> Hi,
>>>> I am doing some XSL-FO development on behalf of a client. I am running
>>>> the 3.7.8 Developer Stamped version of XEP and have noticed some performance
>>>> issues. Rendering an eight page document (attached) takes
>>>> over 4 seconds when running from the command line on a P4 2.2 Ghz Win2K
>>>> laptop with JDK 1.4.2_05. Another rendering product renders the same
>>>> document in less than 1 second, with no visible difference in the formatted
>>>> output.
>>>> I have also run a performance test against the embedded version of the
>>>> product fronted by a servlet running in the Tomcat 5.0.27 web container.
>>>> With eight concurrent users the time taken to render the document varies
>>>> between 12 seconds and 60 seconds. The number of concurrent users tested is
>>>> at the peak end of the scale of actual usage
>>>> in production, but it seems to show that performance degrades very quickly
>>>> under load. However I am investigating this further as there may have been
>>>> other factors involved e.g. memory limitations, or problems with the servlet
>>>> that wraps the renderer.
>>>> In the meantime I have a couple of questions:
>>>> 1. Is there anything in the XSL-FO in the document that is particularly
>>>> bad or inefficient?
>>>> 2. Are the performance times that I am seeing about what you would expect
>>>> for a document of that size, and for that many concurrent users/threads? (I
>>>> would consider this to be a medium-sized document; we
>>>> will certainly have larger documents.)
>>>> I'd appreciate a quick reply as our client needs to have a solution in
>>>> place within a couple of weeks, and right now I can't recommend that they go
>>>> ahead based upon the results that I have seen so far.
>>>> Thanks,
>>>> Paul
===8<===========End of original message text===========
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Fri Aug 20 2004 - 01:16:30 PDT