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