[xep-support] XEP 371 multi-threading

Duncan, David David.Duncan at bskyb.com
Fri Mar 5 07:03:11 PST 2004


Hi,

 I have another performance question. In regard to my previous email
concerning multi-threading, i have discovered that using Oracle OCI driver
causes problems in a muli-threaded application. I believe this is the main
cause for my performance issues and not the xep driver. However i have a
question regarding xep internal transformation step. I use xep to transform
an xml file to xsl-fo and then render the pdf, so i use xep to perform 2
steps. I was wondering if performance gains could be achieved by separating
out the transform step? Perhaps I could use Xalan or Saxon to do the
transform and pass xep the xslfo to render? I beleive xep uses JAXP...and
maybe using another transformation engine (with freedom to optimise the
engine) woudl help. Im also looking at stylesheet improvement such as,
 
	 - Don't use "//" (descendant axes) patterns near the root of a
large document. 
	 - Use xsl:key elements and the key() function as an efficient way
to retrieve node sets. 
	 - Where possible, use pattern matching rather than xsl:if or
xsl:when statements. 
	 - xsl:for-each is fast because it does not require pattern
matching. 
	 - Keep in mind that xsl:sort prevents incremental processing. 
	 - When you create variables, 
	 - <xsl:variable name="fooElem" select="foo"/>
		is usually faster than 
	 - <xsl:variable
name="fooElem"><xsl:value-of-select="foo"/></xsl:variable> 
	 - The use of index predicates within match patterns can be
expensive. 

If anyone has any suggestions or comments that would be much appreciated.

Thanks,
David.
-----Original Message-----
From: owner-xep-support at renderx.com
[mailto:owner-xep-support at renderx.com]On Behalf Of Duncan, David
Sent: Tuesday, March 02, 2004 10:41 AM
To: 'xep-support at renderx.com'
Subject: [xep-support] XEP 371 multi-threading


Hi,

 I am having a major performance problem when upgraded to xep 371. I may
have amde some code errors which ill investigate, but my initial finding
appear to show problems with multi-threading on a mulitiple cpu machine.
Basically i launch a single JVM which initialises XEP bu loading XEP system
properties and by calling com.renderx.xep.gen.backends.H4PDF.init().

Then ,multiple threads are spawned each creating a PrintPublisher class
(note this is a publisher per xsl file. ie we cache the print publisher
object for multiple transforms using the same xsl template),

class DMSPrintPublisher {

	private static final Logger s_logger =
Logger.getLogger(BatchPublishingClient.class);  // log4j is thread-safe
	private static FOTransformer foTransformer;
	private FormatterImpl formatter;
	
    public DMSPrintPublisher(String template, Properties xepProps) throws
CorrespondenceException {
        InputSource xsl = new InputSource();
        InputStream templateInputStream = new
ByteArrayInputStream(template.getBytes());
        xsl.setByteStream(templateInputStream);
        SAXSource saxSource = new SAXSource(xsl);
        
        try {
        	this.formatter = new FormatterImpl(xepProps,
com.renderx.xep.lib.Logger.NULL_LOGGER);
            foTransformer = new FOTransformer(saxSource, formatter);
            foTransformer.setLogger(com.renderx.xep.lib.Logger.NULL_LOGGER);

			foTransformer.setParameter("signature_location",
System.getProperty(DMSConstants.SIGNATURE_LOCATION));
        	
        } catch (Exception e) {
            throw new CorrespondenceException("Could not set up
transformation engine: " + e.getMessage(), e);
        }

    public void publish(String documentData, OutputStream dest) throws
PublishException {
      try {
      	InputStream dataInputStream = new
ByteArrayInputStream(documentData.getBytes());
       	StreamSource xml = new StreamSource(dataInputStream);
            FOTarget foTarget = new FOTarget(dest, "PDF");
            foTransformer.transform(xml, foTarget);
            dataInputStream.close();
            dest.close();
            formatter.cleanup();
        } catch (Exception exc) {
            throw new PublishException(ErrorCodes.RECOVERABLE_SYSTEM_ERROR,
"Failed to perform transform: " + exc.getMessage(), exc);
        }
    }	
 }

My main concern is that when using xep 361 interface we saw the
multi-threaded process being shared across a 4 cpu unix box (running
Solaris8). However, using xep371 (along with code changes due to new
interface), we see 1 cpu maxed out and the rest idle. This reduces
performance by 4 fold. 

Perhaps I have made some errors in coding the publisher...maybe I should
create one FOTransformer (initialised by xep properties) instead of 1 for
each publisher object? Bu this seems to be a side issue. Are you aware of
any potential multi-threading issues with the new version of xep?

Many thanks for your support,

David.





-----------------------------------------------------------------------
Information in this email may be privileged, confidential and is 
intended exclusively for the addressee.  The views expressed may
not be official policy, but the personal views of the originator.
If you have received it in error, please notify the sender by return
e-mail and delete it from your system.  You should not reproduce, 
distribute, store, retransmit, use or disclose its contents to anyone.
 
Please note we reserve the right to monitor all e-mail
communication through our internal and external networks.
-----------------------------------------------------------------------

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo at 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


.
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo at 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



More information about the Xep-support mailing list