[xep-support] Slow performance of com.renderx.util.DeflaterOutputStream / java.util.zip.DeflaterOutputStream on Solaris T2000 / Java 1.6

I am trying to scale my batch PDF processing application on a Solaris
T2000 server. This architecture is supposed to scale to 32 concurrent
threads with very little overhead.

With 32 rendering threads, the CPU utilisation steady states at
approximately 5%. Analyzing a thread dump shows that almost all
threads are executing com.renderx.util.DeflaterOutputStream.write(),
which delegates to java.util.zip.DeflaterOutputStream.write(). I am
struggling to discover the exact nature of this bottleneck. The
threads are in the RUNNABLE state, so they are not blocked on Java
locks. The underlying output stream in a ByteArrayOutputStream.

It seems that there have been a variety of perfomance bugs in
java.util.zip.DeflaterOutputStream.write() over Java's history,
related to JNI overhead of copying data across the native interface.
See the discussion on the OpenJDK list [1] [2].

 - What is the intent of com.renderx.util.DeflaterOutputStream? Is it
a workaround for a performance bug in a particular Java version?
 - Is it also suitable for Java 1.6?
 - Should I consider deferring PDF compression to a post-processing
step using another tool like Multivalent? [3]

I have also tried substituting a 'no-op' version of
com.renderx.util.DeflaterOutputStream (by inserting it ahead of the
classpath). I've tried changing the buffer size and compression ratio,
but I still get very low overall CPU utilisation.

public class DeflaterOutputStream extends java.util.zip.DeflaterOutputStream {
    public DeflaterOutputStream(OutputStream os) {
        super(os, new Deflater(7), 4 * 1024);
    }
}

Regards,

Jason

1 [http://www.nabble.com/Performance-regression-in-java.util.zip.Deflater-td14443189.html]
2 [http://64.233.183.104/search?q=cache:UZcVzRAPIm8J:www.nabble.com/Performance-regression-in-java.util.zip.Deflater-td14443189.html+deflateBytes+slow+java&hl=de&ct=clnk&cd=4&gl=ch&client=firefox-a]
3 [http://multivalent.sourceforge.net/Tools/pdf/Compress.html]
-------------------
(*) 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/terms-of-service.html
Received on Tue Feb 26 06:16:15 2008