RE: Performance Guidance
J: No offense meant, but most people start with the most inefficient ways to generate XML, usually doing a lookup in a remote database (which is slow, but hard to avoid), building an XML string or a DOM tree (which is slow, memory consuming and avoidable) and then feed it to the XSLT processor. I meant to ask--what alternatives do you suggest to that avoidable second step as far as getting to the XSLT processor? thx a lot Matt Savino
RE: Performance Guidance
That's really good to know. Thanks Matt Savino Doesn't XSLT ultimately need it's source XML in a DOM object to run? It depends. One point is that DOM is an interface, and there exist heavyweight and leightweight implementations. Some XSLT processors can work directly from an arbitrary DOM tree as long as read interface is supported. Many XSLT processors prefer to build their own internal representation of the XML tree for efficiency rather than using a DOM implementation from a library, quite a few do this even if they are fed a DOM tree. The internal XML tree representation may or may not resemble a DOM implementation, and may or may not use or provide a DOM conformant interface. Some processors, specifically Xalan, are capable of streaming processing. They analyze the templates and start processing immediately once a sufficiently large subtree is read. Subtrees which has been processed are discarded, so there is never a complete DOM in memory. This work especially well if you are creating a (HTML-) table from a DB query result. J.Pietschmann
Re: Performance Guidance
Savino, Matt C wrote: Doesn't XSLT ultimately need it's source XML in a DOM object to run? Certainly not if you are talking about java processors. Moreover source xml in DOM form often means wastefulness of memory and cpu since almost every xslt processor always builds its own *optimized* input tree (e.g. DTM in xalan, tinytree in saxon). So keep using sax everywhere you can. -- Oleg Tkachenko Multiconn International Ltd
Re: Performance Guidance
Zahigian, Mike wrote: I am using FOP to take a single page of XSL:FO content and convert to PDF. I have embedded FOP in a servlet. When I have one user requesting a page it takes about 6 or 7 seconds to get the page formatted as PDF. It seems like each additional simultaneous request pushes the response time by 6 or 7 seconds. So, if 10 users request pages at about the same time, the 10th user gets his page back in about a minute--and this is only one page. Is this the performance I should expect? What the ideal way to handle the rendering process? Should I create a Rendering object that had a rendering method or should I simply have a class with one static method that renders? Any guidance on how to embed FOP and get better response time is appreciated. The design of the embedding hardly matters for performance. The complexity of the layout usually matters. How much time does FOP need to render your FO from the command line? Does the time include the XSL transformation or is it FO rendering only? Use the -d switch to get timings. Do you use JDK1.3? Is HotSpot enabled? FOP is much slower on JDK 1.2 and earlier. Try to isolate the steps. Apply a profiler. You might find bottlenecks where you'd expect them last. In your case, I strongly suspect the bottleneck is data retrieval, not FO rendering, 7 seconds for a page sounds too much. You ought to get 1-2 pages per second on moderatly dated machines. J.Pietschmann
RE: Performance Guidance
Matt, I'm not sure what you mean by a one FOP processing thread per appserver instance? J., I am getting data out of some javabeans in the form of xml, then this xml is transformed using a stylesheet, then another transformation takes place to create the xsl:fo and then FOP takes over. I'll go ahead and try and profile--you think the bottleneck might be in the transformations and not in the final rendering? Do you have a profiler you can recommend? Thanks very much for the feedback. Mike Z. -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED] Sent: Thursday, June 06, 2002 1:51 PM To: '[EMAIL PROTECTED]' Subject: RE: Performance Guidance I am curently working on a system to only allow one FOP processing thread per appserver instance. You can search my earlier posts for some benchmarking results. Matt Savino Senior Systems Analyst Quest Diagnostics Inc. 33608 Ortega Hwy Building C San Juan Capistrano, CA 92690 949.728.4832 cel - 310-344-0889 pg - 949-452-4566 -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Thursday, June 06, 2002 1:47 PM To: [EMAIL PROTECTED] Subject: Re: Performance Guidance Zahigian, Mike wrote: I am using FOP to take a single page of XSL:FO content and convert to PDF. I have embedded FOP in a servlet. When I have one user requesting a page it takes about 6 or 7 seconds to get the page formatted as PDF. It seems like each additional simultaneous request pushes the response time by 6 or 7 seconds. So, if 10 users request pages at about the same time, the 10th user gets his page back in about a minute--and this is only one page. Is this the performance I should expect? What the ideal way to handle the rendering process? Should I create a Rendering object that had a rendering method or should I simply have a class with one static method that renders? Any guidance on how to embed FOP and get better response time is appreciated. The design of the embedding hardly matters for performance. The complexity of the layout usually matters. How much time does FOP need to render your FO from the command line? Does the time include the XSL transformation or is it FO rendering only? Use the -d switch to get timings. Do you use JDK1.3? Is HotSpot enabled? FOP is much slower on JDK 1.2 and earlier. Try to isolate the steps. Apply a profiler. You might find bottlenecks where you'd expect them last. In your case, I strongly suspect the bottleneck is data retrieval, not FO rendering, 7 seconds for a page sounds too much. You ought to get 1-2 pages per second on moderatly dated machines. J.Pietschmann
RE: Performance Guidance
I mean every other thread has to wait. I have the FOP processor wrapped in a stateless session bean and I limit the number of instances of that bean to one. This is because of the serious performance drop-off we see when FOP is run more than once concurrently. I'm still working out some of the details. Matt Savino -Original Message- From: Zahigian, Mike [mailto:[EMAIL PROTECTED] Sent: Thursday, June 06, 2002 2:13 PM To: '[EMAIL PROTECTED]' Subject: RE: Performance Guidance Matt, I'm not sure what you mean by a one FOP processing thread per appserver instance? J., I am getting data out of some javabeans in the form of xml, then this xml is transformed using a stylesheet, then another transformation takes place to create the xsl:fo and then FOP takes over. I'll go ahead and try and profile--you think the bottleneck might be in the transformations and not in the final rendering? Do you have a profiler you can recommend? Thanks very much for the feedback. Mike Z. -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED] Sent: Thursday, June 06, 2002 1:51 PM To: '[EMAIL PROTECTED]' Subject: RE: Performance Guidance I am curently working on a system to only allow one FOP processing thread per appserver instance. You can search my earlier posts for some benchmarking results. Matt Savino Senior Systems Analyst Quest Diagnostics Inc. 33608 Ortega Hwy Building C San Juan Capistrano, CA 92690 949.728.4832 cel - 310-344-0889 pg - 949-452-4566 -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Thursday, June 06, 2002 1:47 PM To: [EMAIL PROTECTED] Subject: Re: Performance Guidance Zahigian, Mike wrote: I am using FOP to take a single page of XSL:FO content and convert to PDF. I have embedded FOP in a servlet. When I have one user requesting a page it takes about 6 or 7 seconds to get the page formatted as PDF. It seems like each additional simultaneous request pushes the response time by 6 or 7 seconds. So, if 10 users request pages at about the same time, the 10th user gets his page back in about a minute--and this is only one page. Is this the performance I should expect? What the ideal way to handle the rendering process? Should I create a Rendering object that had a rendering method or should I simply have a class with one static method that renders? Any guidance on how to embed FOP and get better response time is appreciated. The design of the embedding hardly matters for performance. The complexity of the layout usually matters. How much time does FOP need to render your FO from the command line? Does the time include the XSL transformation or is it FO rendering only? Use the -d switch to get timings. Do you use JDK1.3? Is HotSpot enabled? FOP is much slower on JDK 1.2 and earlier. Try to isolate the steps. Apply a profiler. You might find bottlenecks where you'd expect them last. In your case, I strongly suspect the bottleneck is data retrieval, not FO rendering, 7 seconds for a page sounds too much. You ought to get 1-2 pages per second on moderatly dated machines. J.Pietschmann
RE: Performance Guidance
I get it. Do you know if I can similarly limit the number of instances of a servlet to one? Mike Z. -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED] Sent: Thursday, June 06, 2002 2:17 PM To: '[EMAIL PROTECTED]' Subject: RE: Performance Guidance I mean every other thread has to wait. I have the FOP processor wrapped in a stateless session bean and I limit the number of instances of that bean to one. This is because of the serious performance drop-off we see when FOP is run more than once concurrently. I'm still working out some of the details. Matt Savino -Original Message- From: Zahigian, Mike [mailto:[EMAIL PROTECTED] Sent: Thursday, June 06, 2002 2:13 PM To: '[EMAIL PROTECTED]' Subject: RE: Performance Guidance Matt, I'm not sure what you mean by a one FOP processing thread per appserver instance? J., I am getting data out of some javabeans in the form of xml, then this xml is transformed using a stylesheet, then another transformation takes place to create the xsl:fo and then FOP takes over. I'll go ahead and try and profile--you think the bottleneck might be in the transformations and not in the final rendering? Do you have a profiler you can recommend? Thanks very much for the feedback. Mike Z. -Original Message- From: Savino, Matt C [mailto:[EMAIL PROTECTED] Sent: Thursday, June 06, 2002 1:51 PM To: '[EMAIL PROTECTED]' Subject: RE: Performance Guidance I am curently working on a system to only allow one FOP processing thread per appserver instance. You can search my earlier posts for some benchmarking results. Matt Savino Senior Systems Analyst Quest Diagnostics Inc. 33608 Ortega Hwy Building C San Juan Capistrano, CA 92690 949.728.4832 cel - 310-344-0889 pg - 949-452-4566 -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Thursday, June 06, 2002 1:47 PM To: [EMAIL PROTECTED] Subject: Re: Performance Guidance Zahigian, Mike wrote: I am using FOP to take a single page of XSL:FO content and convert to PDF. I have embedded FOP in a servlet. When I have one user requesting a page it takes about 6 or 7 seconds to get the page formatted as PDF. It seems like each additional simultaneous request pushes the response time by 6 or 7 seconds. So, if 10 users request pages at about the same time, the 10th user gets his page back in about a minute--and this is only one page. Is this the performance I should expect? What the ideal way to handle the rendering process? Should I create a Rendering object that had a rendering method or should I simply have a class with one static method that renders? Any guidance on how to embed FOP and get better response time is appreciated. The design of the embedding hardly matters for performance. The complexity of the layout usually matters. How much time does FOP need to render your FO from the command line? Does the time include the XSL transformation or is it FO rendering only? Use the -d switch to get timings. Do you use JDK1.3? Is HotSpot enabled? FOP is much slower on JDK 1.2 and earlier. Try to isolate the steps. Apply a profiler. You might find bottlenecks where you'd expect them last. In your case, I strongly suspect the bottleneck is data retrieval, not FO rendering, 7 seconds for a page sounds too much. You ought to get 1-2 pages per second on moderatly dated machines. J.Pietschmann
