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

http://www.ibm.com/developerworks/java/library/j-5things4.html
5 things you didn't know about ... java.util.concurrent, Part 1 (Page last updated May 2010, Added 2010-06-28, Author Ted Neward, Publisher IBM). Tips:

• CopyOnWriteArrayList is a thread-safe variant of ArrayList with all mutative operations (add, set, and so on) implemented to make a fresh copy of the array - ideal for the read-often, write-rarely scenario such as Listeners of a JavaBean event.
• BlockingQueue is a first in, first out (FIFO) Queue which blocks the thread if it tries to get from an empty queue until an item is added by another thread; and for the bounded variety will block the thread on any attempt to insert an item into a full queue until space becomes available in the queue's storage.
• BlockingQueue neatly solves the problem of how to "hand off" items from one thread to another thread without explicitly synchronizing.

• ArrayBlockingQueue can give reader and writer threads first in, first out access (it would be a more efficient to allow readers to run while other readers held the lock, but you'd risk a constant stream of reader threads keeping the writer from ever doing its job.)
• Doing (if Map.get() == null) Map.put() is a race condition; ConcurrentMap supports putIfAbsent() that does the test first then does a put only if the key isn't already stored in the Map.
• SynchronousQueue is a BlockingQueue in which each insert operation must wait for a corresponding remove operation by another thread and vice versa - i.e. the threads always operate synchronously across this queue.

http://www.ibm.com/developerworks/java/library/j-5things5.html
5 things you didn't know about ... java.util.concurrent, Part 2 (Page last updated June 2010, Added 2010-06-28, Author Ted Neward, Publisher IBM). Tips:

• Throttling can sometimes improve the throughput of a system by reducing the amount of contention against a particular resource.
• Semaphore allows you to specify how many threads can concurrently use a shared resource, letting you throttle the contention on that resource to optimize it's availability.
• CountDownLatch holds all threads blocked until a particular condition is met, at which point it releases them all at once.
• ScheduledExecutorService executes a given task at determined intervals or at a specific time, and allows the task to be cancelled at any time.
• java.util.concurrent blocking operations can usually be timed out - this is a huge advantage over synchronizing on monitors and locking; as it means that deadlocks can be avoided by backing off and retrying.

http://www.infoq.com/articles/learnings-five-years-skype-architect
Learnings from Five Years as a Skype Architect (Page last updated April 2010, Added 2010-06-28, Author Andres Kutt, Publisher InfoQ). Tips:

• Keep essential business logic close to the data where it can work most efficiently.
• If you have the capability, maintaining your own database implementation will provide optimal performance in data management.
• Anything that takes more than three sentences to explain to your peers is too complex to be used.
• Promising to deliver each message at least once instead of exactly once makes many implementation details simpler.

http://blog.dynatrace.com/2010/06/15/top-10-performance-problems-taken-from-zappos-monster-and-co/
Top 10 Performance Problems taken from Zappos, Monster, Thomson and Co (Page last updated June 2010, Added 2010-06-28, Author Andreas Grabner, Publisher dynaTrace). Tips:

• More data requested than is actually required - ensure you ask for only the data you need.
• The same data is requested multiple times - batch, cache or coordinate requests, or identify the requests and combine them.
• Inefficient query that uses several requests to get data instead of one detailed request - combine into one request.
• Over-synchronization can often only be seen under heavy load - ensure you have appropriate load tests and contention monitoring in production.
• Too chatty across remote components - trace all remote calls so that these can be analysed.
• Faulty settings and incorrect usage of object-relational mappers cause many inefficiencies - make sure you correctly set the options for your application.
• Memory leaks - monitor heap and take dumps as necessary.
• Memory, CPU, I/O and the database are all restricted shared resources - monitor them and analyse to optimise usage.
• Inefficient pages served to browsers - ensure you optimise download time and profile browser usage.
• Caching too many objects can lead to excessive Garbage Collection - monitor the heap and cache statistics.
• Expensive serialization leads to high CPU usage on both ends of a call. Profile, monitor and optimise these.

http://java.dzone.com/kirk-dominating-consumer
Interview: Kirk Pepperdine, Performance, and the Dominating Consumer (Page last updated June 2010, Added 2010-06-28, Author Geertjan Wielenga, Publisher JavaLobby). Tips:

• The monitor or profiler to use depends on whether the bottleneck is system level (looking for CPU/IO/Memory causes), JVM level (object lifecycles and GC), or application (algorithms).
• There are three key performance indicators: user utilization of the CPU, operating system utilization of the CPU, and garbage collection metrics.
• If the system time is greater than 10% of total CPU and/or it is equal to or greater than user time on a consistent basis, then we have the condition where the operating system is being overutilized/overworked.
• The best way to help your garbage collector is to let your objects die young.

http://carsonified.com/blog/dev/steve-huffman-on-lessons-learned-at-reddit/
Steve Huffman on Lessons Learned at Reddit (Page last updated May 2010, Added 2010-06-28, Author Keir Whitaker, Publisher Carsonified). Tips:

• Design the system to come automatically straight back up after a crash - the quicker it can restart, the more options this gives you. You can even deliberately bounce the service if it can come up quickly - and so workaround slowdown issues (like memory leaks). Use the logs to identify the problem and fix it in the background.
• Separate services so that they are using the appropriate hardware and software that optimises their performance - e.g. one database serving one type of data means it can be very specialised and optimised.
• It is easier to horizontally scale processes than threads - the inter-process communication is solved so it is often just a matter of moving and reconfiguring.
• Schema updates are really painful for big databases - you can?t just add another column or add another table and expect it to perform well. An open schema (table: ID, key, value) allows for much more flexibility and no performance penalty changes to the schema. But you lose relational database consistency mechanisms.
• Statelessness is hugely important in enabling applications to scale easily.
• Cache as much as possible.
• Rate limit requests depending on the requestor: if a requestor is making too many requests, you can limit them more; if the server is under too heavy a load you can decrease the limit on all requests to decrease the load.
• Use disk based memory caching for memory cache overflows.
• Pre-compute as much as possiblr and cache it (persistently).
• Do the minimum amount of work to enable a request to be displayed. If you need to do something else, do it while they?re not waiting for you. Dump it in a queue .

Jack Shirazi Back to newsletter 115 contents