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 068 contents

http://weblogs.java.net/blog/malcolmdavis/archive/2006/07/scale_up_vs_sca.html
Scale Up vs. Scale Out (Page last updated July 2006, Added 2006-07-27, Author Malcolm Davis, Publisher java.net). Tips:

• Scalability is the ability to increase the application throughput in proportion to the hardware that is being used to host the application.
• A scalable application that can handle 100 users on a single CPU hardware, should be able to handle 200 users on 2 CPUs.
• Databases needs: Large shared memory space, Many dependent threads, and Tightly-coupled internal interconnect, and are more suitable to scaling up hardware on a single box
• web-tiers typically have: Small non-shared memory space, Many independent threads, Loosely-coupled external interconnects and are more suitable to scaling out hardware on multiple boxes
• Multiple applications runnning on one bib box makes root cause analysis more difficult, and they can interefere with each other as well.
• [Article argues the case that using multiple smaller boxes is better than using one big box for many reasons, including reducing conflicts, easier analysis, easier expansion, more accurate sizing, failover, and more].
• Scalability vs Performance: I can send any number of packages to anywhere and it will get there with 24 hours using FedEx. But if I want a package moved across town in a hour, Fed Ex can't do it.

http://builder.com.com/5100-6370_14-6095050.html?tag=sc
java.nio's features (Page last updated July 2006, Added 2006-07-27, Author Peter Mikhalenko, Publisher builder.com). Tips:

• NIO offers: non-blocking asynchronous I/O; memory mapping files; block I/O rather than byte I/O; locking files or parts of files.
• One thread can be blocked on a channel operation, and another thread can close the channel which awakens the blocked thread with an channel closed exception.
• ScatteringByteChannel and GatheringByteChannel interfaces have read() and write() methods that take a sequence of buffers rather than a single buffer, with I/O operating atomically where possible.
• In non-blocking mode, a call to write a large buffer over a slow socket would just queue up the data (possibly at the OS or network level) and return immediately.
• Selectable channels can be multiplexed via the Selector class.

http://crazybob.org/2006/07/hard-core-java-threadlocal.html
ThreadLocal (Page last updated July 2006, Added 2006-07-27, Author Bob Lee, Publisher crazybob). Tips:

• A thread local variable gives each thread has a separate value.
• Explicitly clear thread local variable values in a finally block to prevent memory leaks.
• Consider whether or not the code which sets the thread local value can be reentered - non-rentreent code can fail using if (threadLocal.get() != null) throw new IllegalStateException();
• To support multiple reentrance with thread local values, you need to keep a stack of previous value. You can use the thread stack, e.g. method(){Context previous = threadLocal.get(); ...; finally {threadLocal.set(previous);}}
• Thread local access isn't expensive but it's also not so cheap that you should use it unnecessarily.
• Code which depends directly on a ThreadLocal can be difficult to test.

http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=400
Web Service integration lessons (Page last updated June 2006, Added 2006-07-27, Author Len Takeuchi, Publisher ACMQueue). Tips:

• ASPs may or may not provide SLAs (service-level agreements) on their availability and performance, and there will inevitably be some unscheduled downtime that may last a few hours or even days. The application integrating with the ASP needs to be designed to provide as much of its functionality as possible even if an ASP is not available.
• An application integrating with an ASP should not cache results of DNS lookups on the ASP's access points beyond its TTL (time to live) values.
• Java's default behavior for caching a successful DNS lookup is to cache forever, which is inappropriate for ASP integration; the caching period will have to be adjusted to something more appropriate to ensure that the application continues to work after an ASP's IP address changes.
• ASPs protect themselves against a particular organization using too much of their resources by placing limits on: Number of API login sessions; Rate at which requests are submitted; Request size; Query size; Number of instances returned from a query; Execution time of requests.
• ASP request limitations are published with the API and code should be designed to gracefully handle attempts to exceed the limitations.
• Applications integrating with ASPs have to be prepared for failures caused by unreliable communications, ASP unavailabilities, and resource usage limitations imposed by ASPs.
• Communication problems such as being disconnected or timing out while waiting for a response from the ASP are particularly problematic since the application does not know for sure whether the operation has completed successfully. The application needs to do its best to determine after the fact whether the request has been successfully processed. (One approach is to record a unique request ID in a custom field so that subsequent queries can determine the status of the request).
• The main problem with performance when using the APIs provided by ASPs is the per-call overhead from: internet latency; transmission time; marshalling and un-marshalling (xml/SOAP); and authentication/authorization checking.
• For Salesforce.com 150 milliseconds is the absolute floor for any call - any call will take 150 milliseconds plus transmission time, marshalling and un-marshalling time, and actual processing time for the logic of the request.
• If the ASP supports compression, it should be used to minimize transmission time. (Set the AcceptEncoding and ContentEncoding HTTP header fields to the compression format.)
• A web service application will perform poorly if many separate requests are sent to the ASP. The application should minimize calls by caching data as much as possible (refreshing it appropriately), and using APIs that send modifications together, retrieving information in groups.
• It is important to identify slow operations and use them sparingly.
• The performance of the XML parser used by the application is particularly important.

http://cretesoft.com/archive/newsletter.do?issue=129&locale=en_US
Fast Exceptions (Page last updated June 2006, Added 2006-07-27, Author Heinz Kabutz, Publisher cretesoft). Tips:

• RIFE uses empty fillInStackTrace() methods to make Exception creation much faster.
• Reusing an existing Exception is even faster than using new Exception(){public Throwable fillInStackTrace() {return null;}}

http://blogs.sun.com/roller/page/alanb?entry=heapdumponoutofmemoryerror_option_in_5_0u7&feed=RSS
HeapDumpOnOutOfMemoryError (Page last updated May 2006, Added 2006-07-27, Author Alan Bateman, Publisher Sun). Tips:

• -XX:+HeapDumpOnOutOfMemoryError option available in 1.5.0_07 and 1.4.2_12, producing an hprof binary format heap dump
• Analyse hprof heap dumps using HAT, or jhat or YourKit (has an hprof import option)
• hprof heap dumps are platform independent and so you don't need to analyze the dump on the same system that produced it
• running with -XX:+HeapDumpOnOutOfMemoryError does not impact performance - it is simply a flag to indicate that a heap dump should be generated when the first thread throws OutOfMemoryError.
• -XX:+HeapDumpOnOutOfMemoryError does not work with -XX:+UseConcMarkSweepGC in 1.5.0_07

Jack Shirazi Back to newsletter 068 contents