JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 081 contents

http://www.fasterj.com/articles/javascript.shtml
Javascript Performance (Page last updated August 2007, Added 2007-08-29, Author Kirk Pepperdine, Publisher fasterj.com). Tips:

• javascript performance has three issues in priority order: network communications; CPU usage; memory leaks.
• Avoiding using getters and setters in favor of direct access to avoid the overhead of a method call is still valid advice for Javascript (not valid for Java where the inlining will eliminate the overhead).
• Different javascript implementations have different performance profiles - Rhino (the Java implementation) appears to be one of the best.
• JavaScript can CPU bound the client machine if you try to do too much with it

http://cretesoft.com/archive/Issue147.html
The Law of the Distracted Spearfisherman (Page last updated June 2007, Added 2007-08-29, Author Dr. Heinz M. Kabutz, Publisher Java Specialists' Newsletter). Tips:

• Generate thread dumps by press CTRL+Break on Windows and CTRL+\ on Unix in the console window, by sending a kill -3 to the Java process in unix, or using jstack (jstack in Java 5 doesn't report deadlocks, but does in java 6).
• Make sure that you know exactly what every thread is doing.

http://www.devx.com/xml/Article/34677
Multithreaded XML Transformations (Page last updated May 2007, Added 2007-08-29, Author Todd Lauinger, Publisher devX.com). Tips:

• [Article runs through an example of improving the performance and memory of an XSLT transformation]
• A simplistic JAXP transformation appears to load the entire input document into a DOM structure in memory before even starting the transformation process. A small file would be transformed in minimal memory and time. But a 275 MB input file nearly runs out of memory in a virtual machine sized to 1 GB, so gigabyte-sized input files can't be processed this way.
• You should subdivide the input XML document into manageable chunks; each Record element is a manageable chunk and can be transformed in isolation of any other Record element. You need to change your XSLT transformation slightly to transform just an individual record.
• The dom4j open source library supports parsing huge XML input files incrementally by loading only one portion of the XML document sub-tree into memory at a time.
• Cache the XSLT transformation if this same transformation is going to be applied hundreds or perhaps even millions of times, e.g. using transformer = cachedXSLT.newTransformer();
• Make sure the XML declaration for each individual record transformed is omitted by adding at the top of the output file: transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes");
• Copy each individual record into its own XML document - after use you can tell dom4j to delete the memory used to parse that portion of the huge XML input file via the detach() method call: Element record = path.getCurrent(); Document newDocument = DocumentHelper.createDocument(); newDocument.add(record.createCopy() ); record.detach();
• By processing XML portions one at a time and releasing memory as you go, you can process very large files in 20MB of memory.
• Thread pools are important for processing multiple small tasks, as the overhead to create and destroy threads is large compared to quick tasks. Create a fixed-size thread pool as follows: ExecutorService executor = Executors.newFixedThreadPool(totalThreads);
• An executor object handles queuing the tasks for you - create a task, using either the Runnable or Callable interface, and then tell the executor to execute that task when a thread in the pool is available: executor.execute(new XSLTRunnable(transformer, outputWriter, newDocument));
• You need to put thought into restructuring a program to take advantage of that thread pool.
• The best candidates for being thread pooled are actions that can be executed in any order, and any object passed into a task executed in parallel must be safe to be accessed in parallel.
• XSLT transformation and output generation can each be run in parallel.
• By parallelising an XSLT tranform so that the transform and output of portions can be run concurrently, performance is improved even on a single-CPU machine as the program can use the CPU while waiting on I/O. The same program runs even faster on a multi-CPU machine.

http://www.infoq.com/articles/pritchett-latency
The Challenges of Latency (Page last updated May 2007, Added 2007-08-29, Author Dan Pritchett, Publisher infoQ). Tips:

• The speed of light dictates that even if we can route packets at the speed of light it will take 30ms for a packet to traverse the Atlantic.
• An architecture that is tolerant of high latency will operate perfectly well with low latency, but the opposite is usually not true.
• The web has lead to expectations of synchronous request/response interactions with low latency between the request and response. This pattern does not lend itself to high latency connections.
• Latency tolerance can only be achieved by introducing asynchronous interactions to your architecture.
• Asynchronous architectures need more than changing the request/response from a call to a series of messages - the client is still expecting a response in a deterministic time.
• Asynchronous architectures shift from deterministic response time to probabilistic response time, removing determinism.
• You need to tackle your persistence model early in your architecture and require that data can be split along both functional and scale to distribute your architecture widely.
• Splitting data is more complex than splitting applications.
• A model that can tolerate latency should accept that state will not always be perfect and consistency will occur asynchronously to the initiating operations.
• You can have at most two of the three of Consistency, Availability, and Partitioning (CAP model).
• Making your disaster recovery centre part of your (load balanced) active system improves performance and ensures that it is exercised.

http://weblogs.java.net/blog/sdo/archive/2007/05/how_to_test_con.html
How to test container scalability (Page last updated May 2007, Added 2007-08-29, Author Scott Oaks, Publisher java.net). Tips:

• Scaling tests need to consider the pause time between tests and the machines required to generate the client load (without causing artificial bottlenecks, as that can easily invalidate a test).
• If the client is a bottleneck, you're measuring the client performance, not the server performance.
• 16000 threads, will require more than 4GB of address space so needs to use 64-bit architectures (OS and JVM).
• The only realistic benchmark is your own application.

http://weblogs.java.net/blog/emcmanus/archive/2007/05/making_a_jmx_co_1.html
Making a JMX connection with a timeout (Page last updated May 2007, Added 2007-08-29, Author Eamonn McManus, Publisher java.net). Tips:

• Explicitly set a timeout on a socket connection by using Socket s = new Socket(); s.connect(new InetSocketAddress(host, port), timeoutInMilliSeconds);
• If making few connections, to timeout a connection you can reate the connection in another thread, and wait for that thread to complete. If it doesn't complete before your timeout, you just abandon it.
• [Article implements a JMXConnector connection timeout].

http://www.ddj.com/dept/java/199902669
Spin Buffers (Page last updated June 2007, Added 2007-08-29, Author Prashanth Hirematada, Publisher DrDobbs). Tips:

• Producer-consumer patterns are often performance bottlenecks because one thread has to lock the other one out when both are accessing the shared resource area.
• Consider using Spin buffers if you are writing high-performance applications - they eliminate the need for synchronization (they don't even employ low-level atomic instructions such as Compare & Swap).
• [Article discusses implementations for Ring buffers and Spin buffers].
• Spin buffers are sensitive to impedance mismatch, slow readers slow down the writer and visa versa. The performance peaks when reads/writes are called at matching frequency.
• The performance gains that Spin buffers deliver make an ideal choice for a wide range of applications such as game server engines, graphics, networking, memory managers, and other high-performance applications.

Jack Shirazi Back to newsletter 081 contents