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