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

http://kirk.blog-city.com/accu_roundup.htm
ACCU Roundup (Page last updated April 2009, Added 2009-05-28, Author Kirk Pepperdine, Publisher pepperdine). Tips:

• When gathering functional requirements be sure to gather important performance requirements.
• The architectural performance tool is a benchmark. The purpose of the benchmark in this context is to ensure that your architecture supports your performance requirements as you understand them.
• Some products work better when they are integrated into a project up front - retro-fitting a product that is needed for performance afterwards can be costly or you won't receive the full benefit.
• Performance testing is *not* unit testing - you can unit test for small amounts of functionality but rarely can you performance test small amounts of functionality. Testing small amounts of functionality is akin to micro-benchmarking, and is mostly not useful. Performance testing usually needs to be done at the compopnent level.

http://jeremymanson.blogspot.com/2009/04/faster-logging-with-faster-logger.html
Faster logging with faster logger classes (Page last updated April 2009, Added 2009-05-28, Author Jeremy Manson, Publisher jeremymanson). Tips:

• java.util.Logger.log() is not scalable to high throughput due to concurrent updating and lock acquisition overheads. The article suggests a number of changes that improves throughput (incorporated into JDK 7).
• If you have a rarely updated concurrent array you should be using the non-blocking CopyOnWriteArrayList instead of locking the array.
• Locks protecting single fields can often be replaced by making the field volatile and reading to a local variable on access to ignore concurrent changes after access.
• Don't have a synchronized array that is almost never updated.

http://www.ibm.com/developerworks/aix/library/au-perf_tuning/
Performance tuning considerations in your application server environment (Page last updated January 2009, Added 2009-05-28, Author Sean Walberg, Publisher IBM). Tips:

• Static server performance: maxes at 100 requests/second if disk limited by I/O (service time of 10ms constrained by having to seek disk heads); files served from a memory cache increases the throughput capability.
• Putting more steps between the user and the final page makes things slower and decreases system capacity.
• On one server it is easy to share the user's session state in a shared memory segment. Once you have two servers, you need to find a new way to share state, such as a database. The database (or other memory sharing mechanism) will be slower than the memory access, so two servers will not be twice as fast as one.
• If the rate of requests entering a particular queue exceeds the rate at which the queue can process requests, then the requests back up. When requests back up, the service time is unpredictable.
• Tuning queues is a balancing act. Too small, and you'll drop users when you still have capacity. Too big, and you'll try to serve more users than your system can handle, causing poor performance for everone.
• The recommended approach is to queue any users before the application server, such as on the Web server. This means that the Web server keeps the connection open with the Web client and issues the request once the next available application server slot is freed. The application server is tuned to handle only enough requests per second that it can dispatch in a timely manner.
• Being able to know what's going on in your system is the key to being able to scale it. Parts of your code that you think are not properly optimized may not end up being a problem. Only proper measurement can tell you what's going on.
• Caching means to store the results of an expensive request for later use. When considering caching, ask yourself "Does this information have to be fresh?" If not, it might be a candidate for caching.
• A complementary technique for caching is to invalidate the cached entry when the underlying data changes. one of the actions performed on saving might be to remove the cached version.
• Techniques such as caching and asynchronous processing can reduce the workload on the application by reusing previous work or by farming the bulk of the work to another machine. Providing instrumentation hooks in your application lets you zero in on your hotspots in near real time.

http://www.infoq.com/news/2009/05/8-Best-Practices-Scalability
8 Best Practices to Improve Scalability (Page last updated May 2009, Added 2009-05-28, Author Abel Avram, Publisher infoQ). Tips:

• Stay away from the database as much as possible.
• Cache as much as feasible - an in-memory cache is better than an on-disk one, which in turn is better than a remote or a relational database.
• Caching coarse-grained objects is better than caching fine-grained ones.
• Don?t store transient state (like session state) permanently.
• Put things as close as possible to where they are supposed to be delivered.
• If more than one request needs unique access to the same resource, control access with first come first fully served letting others wait, rather than letting multiple threads interleave service of requests.
• Use asynchronous pipelines to service requests.
• Minimize network chatter - network communications are considerably slower than in-memory ones.

http://blog.dynatrace.com/2009/05/04/performance-management-in-continuous-integration/
Performance Management in Continuous Integration (Page last updated May 2009, Added 2009-05-28, Author Andreas Alois, Publisher dynaTrace). Tips:

• Common major limited resources are CPU, Memory, Disk, network bandwidth, threads, database connections.
• CPU and Memory are scalable by hardware. Network and sequential shared resource access can only be scaled by changing the application behavior and architecture.
• Architectural changes involve a lot of work and cost time and money. Your primary goal must be to discover architectural problems as early as possible.
• About 50 percent of later performance problems can already be found in development.
• Continuous Integration Performance Management must be automated as it has to be part of the Continuous Integration process.
• Small functional unit tests are not well suited for performance testing, but combinations of existing functional test cases can provide the basis for automated performance tests.
• For performance testing, test cases should also have an execution time greater than one second at least.
• The main criteria for which to check during architecture validation: Number and efficiency of database queries; Number of remote calls and transferred data volume; Memory consumption of a specific transaction; Usage efficiency of shared resources.
• For performance test regression analysis you need to collect performance diagnosis data for each automated test run - or at regular intervals like at the end of each development iteration. These test runs need to then be automatically compared analyzing differences in the execution behavior of test cases.

http://blogs.oracle.com/olaf/2009/04/java_performance_the_return_of.html
The Return of the Usual Suspects (Page last updated April 2009, Added 2009-05-28, Author Olaf Heimburger, Publisher Oracle). Tips:

• Avoid creating unnecessary objects - for example Boolean.TRUE and Boolean.FALSE are the only two booleans that are ever needed.
• StringBuilder is better than StringBuffer, though both are usually better than using string concatenation to build strings.
• Avoid doing the same thing repeatedly in a loop, if you can do it once and cache the result.
• Avoid the DriverManager API as this does not allow you to provide connection pools (instead use a DataSource).

http://www.developer.com/java/data/article.php/3810366
Don't Be a Slave of the File System (Page last updated May 2009, Added 2009-05-28, Author Liviu Tudor, Publisher Gamelan). Tips:

• Access of remote files can easily cause pauses of seconds to your interface. You should make such access asynchronous e.g. by spinning off the access into a separate thread while continuing to be responsive and progressing in the UI.
• [Article implements a framework for reading in the background using callbacks to alert the application when data is ready].

http://java.dzone.com/tips/getting-jvm-heap-size-used
Using the Java Runtime API for JVM Memory Details (Page last updated May 2009, Added 2009-05-28, Author Viral Patel, Publisher javaLobby). Tips:

• Runtime.freeMemory, Runtime.totalMemory, and Runtime.maxMemory give basic information about the JVM heap memory.
• ManagementFactory.getMemoryMXBean() gives more detailed information about the JVM heap memory and some OS level memory information.

Jack Shirazi Back to newsletter 102 contents