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

http://highscalability.com/blog/2010/10/15/troubles-with-sharding-what-can-we-learn-from-the-foursquare.html
Troubles with Sharding - What can we learn from the Foursquare Incident? (Page last updated October 2010, Added 2010-10-28, Author Todd Hoff, Publisher highscalability.com). Tips:

• [Although the article is about shards, the tuning suggestions are generic and really apply to many systems]
• Use more powerful servers - scaling-up is often the best solution.
• Spread your load over more cores and servers
• Design/Enable components to be movable (ideally dynamically) so that they can each separately move to a system with lower load.
• Can your data be moved to another node fast enough to fix overload problems?
• Monitor request queues and memory and fragmentation, and have limits that trigger a contingency plan when limits are exceeded.
• Prioritize requests so management traffic can be received by nodes even when the system is thrashing. Requests should be droppable, prioritizable, load balanceable, etc rather than being allowed to take down an entire system.
• Have the ability to turn off parts of system so load can be reduced enough that the system can recover.
• Consider whether a read-only or restricted backup version of the system could be usable for maintaining restricted operations after catastrophic failure while repairs are going on.
• Use an even distribution mechanism to better spread load.
• Replicate the data and load balance requests across replicas.
• Monitor resource usage so you can take preventative action. Look for spikes in disk operations per second, increased request queue sizes and request latency.
• Build in automated elasticity, sharding, and failure handling.
• Enable background reindexing and defragmentation.
• Continually capacity plan to continually adjust resources to fit projected needs.
• Test your system under realistic high load and overload conditions. Integrate testing into your build system.
• Use incremental algorithms that just need an event and a little state to calculate the next state, e.g. a running average algorithm rather than one that requires all values for for every calculation. This reduces data flow requirements as data can be discarded from caches more quickly.
• Separate historical and real-time data.
• Use more compact data structures.
• If you are expecting that all your data will not fit in RAM, then make sure your IO system isn't the bottleneck.
• Single points of failure are not the end of the word, but you need to know about them and work it into your plans for contingency planning.
• Figure out how you will handle downtime. Let people know what's happening and they will still love you.

http://www.ibm.com/developerworks/java/library/j-5things10.html
5 things you didn't know about ... Java Database Connectivity (Page last updated August 2010, Added 2010-10-28, Author Ted Neward, Publisher IBM). Tips:

• JDBC ResultSets can be scrollable, which might be useful for efficiently finding specific rows if your query returns ordered results. But scrolling ResultSets usually requires an open network connection, so this may not be desirable.
• JDBC ResultSets can but updateable, this might be more efficient than executing a separate update query (it would depend on the implementation). But updating ResultSets usually requires an open network connection, so this may not be desirable.
• JDBC comes with four disconnected RowSets that allow you to manipulate the ResultSet data without maintaining a database connection: CachedRowSet (a disconnected Rowset); WebRowSet (a CachedRowSet XML tranforms); JoinRowSet (a WebRowSet that can JOIN wjile staying disconnected); FilteredRowSet (a WebRowSet that can filter).
• Statement.executeBatch lets you execute more than one SQL statement within one network round-trip.

http://kirk.blog-city.com/verbose_gc_logging.htm
verbose gc logging (Page last updated August 2010, Added 2010-10-28, Author Kirk Pepperdine, Publisher kodewerk). Tips:

• turn on GC logging, it is essential and has less than 1% overhead.

http://java.dzone.com/news/scalable-system-design
Scalable System Design Patterns (Page last updated October 2010, Added 2010-10-28, Author Ricky Ho, Publisher JavaLobby). Tips:

• Load distributer on the front end deploying requests based on some policy. More efficient for stateless requests, but can handle stateful using stickiness.
• A Scatter and Gather distributer multicasts (sub)requests to multiple workers, which calculate (sub)results which the Scatter and Gather distributer consolidates and returns
• A Result Cache holds previous request results cached and serves those if available.
• A shared space (JavaSpaces or blackboard) architecture allows multiple components to continually update a request until the request server determines the request is complete and can be returned.
• A Pipe and Filter architecture connects components with queues which can be asynchronous processed until the final result is available, maximizing throughput.
• The Map Reduce architecture targets jobs where disk I/O is the major bottleneck, using a distributed file system so that disk I/O for a particular request can be done in parallel, minimizing latency.
• An Execution Orchestrator holds work and passes it to a worker as soon as one comes available.

http://www.javaspecialists.eu/archive/Issue187.html
Cost of Causing Exceptions (Page last updated August 2010, Added 2010-10-28, Author Dr. Heinz M. Kabutz, Publisher The Java Specialists' Newsletter). Tips:

• Using exceptions for execution control in unexceptional situations is not recommended as it makes reading the code very difficult.
• Creating an exception is expensive because of the initialization in the fillInStackTrace() method.
• Exceptions raised from the JVM itself (e.g. NullPointerException, ClassCastException, ArrayIndexOutOfBoundsException) can be extremely fast as after a while the (HotSpot) virtual machine just returns the same exception object with no stack trace. This would make debugging difficult if you get that.
• You can use the -XX:-OmitStackTraceInFastThrow to turn off the ability of the JVM to throw fast stackless exceptions.

http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1519118,00.html
Seven quick tips for better performance requirements (Page last updated August 2010, Added 2010-10-28, Author Oliver Erlewein, Publisher SearchSoftwareQuality.com). Tips:

• Ensure terms for describing project performance are understood: What does performance mean in this project context? What is stress? What is concurrency? What is a transaction? etc.
• Paint a picture which the performance requirements should reflect - how many users, how many are concurrent, what are the usage patterns and baselines, etc.
• Infrastructure design and architecture documents are key - discuss why products were chosen and if there were any decisions based on performance.
• See if components have known limitations and tuning guides. Note network speeds, firewalls and load balancers and their maximum capacities and calculate if any of these clashes with the requirements you have.
• A requirement defines at least context and the expected throughput, response time (preferably as percentile), max error rate, sustained amount of time and whether the requirement is related to load, stress, or performance. Context describes such things as functions executed, time of day, type of processing, other services running (conflicting), environment, configuration or settings, number of users, scalability, expected maximum load of systems, and anything else that can influence the system results.

Jack Shirazi Back to newsletter 119 contents