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

http://resources.devx.com/Java/Article/47975
How Java EE 6 Scopes Affect User Interactions (Page last updated March 2012, Added 2012-04-29, Author Leonard Anghel, Publisher devX). Tips:

• JEE6 Request scoped objects (single HTTP request per user) live for the processing duration of a single HTTP request-response.
• JEE6 Session scoped objects (mulitple HTTP requests per user) live for the duration of a user session with a web application, which typically lasts across multiple HTTP requests, until the session times out. The Session scoped objects are bound to the session object.
• JEE6 Application scoped objects (all users share the state) live for the duration of a user session - as with Session scoped objects - but the objects are available across all pages that are part of the application, not only from the session object.
• JEE6 Conversation scoped objects (controlled session) live from the begin() call to the end() call of the Conversation object, and can be propagated across redirects.
• JEE6 Dependent scoped (single HTTP request) is the default scope if no scope is specified; Dependent scoped objects are associated with a Bean and so live for exactly the same length as the Bean - i.e. typically one HTTP request.

http://highscalability.com/blog/2012/2/27/zen-and-the-art-of-scaling-a-koan-and-epigram-approach.html
Zen and the Art of Scaling - A Koan and Epigram Approach (Page last updated February 2012, Added 2012-04-29, Author Russell Sullivan, Publisher highscalability). Tips:

• There are probably around 20 classic bottlenecks. Some are: CPU, NIC overload, memory fragmentation, disk seeks, swap, thread deadlock, packet loss. Each requires a separate monitoring mechanism.
• The key to scalability is the finest granularity of locking, where the "lock" is not a specifically thread-lock but anything that is not inherently scalable.
• Structured data (classic RDBMS tablees) is superior in performance, but inferior in flexibility.
• Statelessness scales forever. Scalability is all about loose coupling. Identify the single points of failure.
• The art of scaling is getting done what needs to be done while staying as close to statelessness as possible, without introducing unneeded complexity by doing so.
• Key-value and sharded data will scale almost infinitely
• Profiling, tracing, monitoring should be built in from the beginning.
• To geo-distribute everything needs to be loosely coupled; Static content scales.
• Push CPU-intensive execution to where CPU capacity is spare - this can be the client.
• Vendor lock-in is an anti-scale pattern.
• The cloud scales (except for disk I/O intensive apps); Hadoop scales; Async message queues scale;
• Use async in-RAM data storage when possible
• Compression can be used: to keep more data in RAM; to reduce disk I/O; to reduce network traffic; to minimize horizontal scaling. It is a space-CPU tradeoff, appropriate when you have spare CPU.
• Using your own servers for normal load and cloud instances to handle spikes is cost effective, but can be really complicated if you need to sync data to the cloud.
• Long and short running queries can not exist together efficiently. Try to segregate your workloads.
• Consider relaxing ACID for long running queries (i.e. batch them).

http://blog.empathybox.com/post/19574936361/getting-real-about-distributed-system-reliability
Getting Real About Distributed System Reliability (Page last updated March 2012, Added 2012-04-29, Author Jay Kreps, Publisher empathybox). Tips:

• Properly designed large scale websites have no planned downtime and handle machine failures without interrupting service.
• Horizontally scalable system components include Hadoop, Cassandra, Voldemort.
• Reliability of systems usually use an assumption of independent failure of components to estimate reliability. It is likely that the independence of failures is wrong, i.e. some failures are more likely to cause or correlate with other subsequent failures elsewhere in the system.
• The best measure of reliability is: continuous hours of successful production operations.

http://drdobbs.com/blogs/parallel/232700457
Java Concurrency: Queue Processing, Part 1 (Page last updated April 2012, Added 2012-04-29, Author Eric Bruno, Publisher Dr. Dobb's). Tips:

• wait(), notify(), and notifyAll() operate on an object's monitor to synchronize operations across a group of threads. The waiting thread needs to own the object's monitor: synchronized (obj) {while ( condition ) { obj.wait(); // perform some action}}. The thread that signals the waiting thread(s) will call notify() or notifyAll() on the same monitor object: synchronized (obj) {obj.notify();}
• Calling notify() wakes up a (random) single thread waiting on the monitor, while notifyAll() wakes up all of the threads waiting on the monitor. Calling notify() is more efficient as it results in fewer thread context switches, but notifyAll() is appropriate when you want to wake up multiple threads because there is a batch of work available to process concurrently.

http://java.dzone.com/articles/gaplist-lightning-fast-list
GapList - a lightning-fast List implementation (Page last updated March 2012, Added 2012-04-29, Author Thomas Mauch, Publisher JavaLobby). Tips:

• GapList offers efficient random access to elements by index and at the same time efficient adding and removing elements to and from the head and tail of the list.
• ArrayList is usually faster and consumes less memory than LinkedList, but add/delete operations at the beginning or interior of an ArrayList can be slower than LinkedList (especially as the list size grows).
• GapList is generally as fast as or faster than ArrayList and LinkedList for most types of expected operations, though slightly slower than ArrayList in the case of completely random add and remove operations.
• GapList is not thread-safe and is unlikely to provide optimal performance if multiple synchronized threads are operating on different parts of the list.
• The memory usage of GapList is comparable to ArrayList.

http://plumbr.eu/blog/solving-outofmemoryerror-dump-is-not-a-waste
Solving OutOfMemoryError (part 6) - Dump is not a waste (Page last updated March 2012, Added 2012-04-29, Author Nikita Salnikov-Tarnovski, Publisher Plumbr). Tips:

• Try a larger heap or adding more memory to the machine - if its's not a leak, this may work.
• Attaching a memory profiler can make an application much slower.
• You can obtain a heap dump with the -XX:+HeapDumpOnOutOfMemoryError and with the jmap command line tool, and various profilers as well as jconsole. Be aware that creating the dump tends to freeze the application for seconds/minutes depending on how big the JVM heap is.
• In order to find a memory leak, you need to have the application get into the state where the leak is relatively obvious, i.e. uses a noticeable amount of memory.
• Eclipse MAT is a nice tool for analysing JVM heap dumps.

Jack Shirazi Back to newsletter 137 contents