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

http://gridgain.blogspot.com/2011/01/collocation-first-rule-of-distributed.html
Collocation - First Rule Of Distributed Programming (Page last updated January 2011, Added 2011-04-27, Author Dmitriy Setrakyan, Publisher gridgain). Tips:

• Sending computation to the nodes where the accessed data is residing is a key component in achieving better scalability
• Fetching data from other nodes for brief periods of time just to perform a quick computation and discard the data is common but bad for scalability.
• Making cache operations local rather than remote fetch is good for performance and scalability.

http://khangaonkar.blogspot.com/2011/03/when-to-use-java-volatile-keyword.html
When to use the Java volatile keyword? (Page last updated March 2011, Added 2011-04-27, Author Manoj Khangaonkar, Publisher The Khangaonkar Report). Tips:

• If a field is declared volatile, Java ensures that all threads see a consistent value for the field.
• For access and updates by different threads on a simple variable there is no guarantee that any thread will see the value that any other thread has written to the variable.
• To ensure multiple threads see a write to a variable in a timely fashion, that variable needs either to be assigned/read in a synchronized block, or it needs to be volatile
• With synchronization, locking is involved, and the synchronized block is executed atmoically with respect to any other thread going through the same lock.
• With volatile variables, no locking is involved.
• Compound operations should be executed in a synchronized block if other threads need to see the result of the operation as atomic (i.e. as if either all the operations or none have occurred).
• All ++ or += and similar operations are compound operations that involve both reads and writes, so should be executed in synchronized blocks rather than relying on a volatile variable.
• Fields declared final are guaranteed to be visible to other threads without synchronization or volatile.
• JDK5 introduced atomic variable classes such AtomicInteger, AtomicLong which extend the volatile concept to compound operations such as read-modify-write. Instances of these classes can be used in place of a volatile field or synchronized field.

http://www.oracle.com/technetwork/articles/java/securityperf-rest-ajax-177520.html
Security and Performance Tuning of a REST and Ajax Application (Page last updated January 2011, Added 2011-04-27, Author Julien Dubois, Publisher Oracle). Tips:

• The client side of an AJAX application - in page display - is typically where most performance problems occur, so effort needs to be spent in reducing page display time.
• All static data should be served separately: ideally hosted on a cookie-free domain by a specific Web server or Content Delivery Network (CDN).
• Static data should be compressed, using gzip or specific compressors (e.g. ShrinkSafe on JavaScript).
• The number of served files should be minimal, because each one requires a separate HTTP connection.
• Images should be combined and served using sprites, which uses CSS to display parts of a larger image containing many small images.
• "expires", "last-modified" and "ETag" headers should be configured to forever for static files (the browser stores such files in its cache). When you want to change a cached-forever file, use a version number in the URL to specify a new version of the static file.
• Use gzip to compress all dynamic content.
• Cache slowly changing data for a day browser-side.

http://merbist.com/2011/01/31/designing-for-scalability/
Designing for scalability (Page last updated January 2011, Added 2011-04-27, Author Matt Aimonetti, Publisher merbist). Tips:

• For browser pages that are unchanging except for a small (e.g. customized to the user) portion, you can still cache the page and use Javascript to fetch the the custom data from the backend and to modify the cached http at the client?s browser level directly.
• As your system gets more traffic, DB or network writes becomes your bottleneck. Denormalize to avoid contention, shard your data in silos, or write to cache and flush from cache when the data store is available and not overwhelmed.
• Use async processing: queue the information needed to run the operation later - you control the amount of workers and therefore the amount of maximum concurrent writes. Advantages include that you can coalesce or remove outdated/duplicated processing; you can assign more workers to some message types; you don't let the client hang while you?re processing; you can temporarily increase workers to handle spikes; failed async jobs can be restarted.
• Monitor/benchmark/load test/profile your app.
• Design so that each layer/component/unit is responsible for itself, only knows about itself, and has limited interactions with other layers. This is particularly important when designing a scalable app because you will often need to swap parts to optimize each part of the system.

http://www.ibm.com/developerworks/cloud/library/cl-cloudapppractices/index.html
Best practices to architect applications in the IBM (Page last updated February 2011, Added 2011-04-27, Author Cloud Christina, Lau Valentina Birsan, Publisher IBM). Tips:

• The distance between the end users to the data center matters; consider how this affects your service and whether the cloud implementation handles dynamically mapping requests to a nearer data centre, or does your application need to provide a similar capability?
• A cloud environment is about dynamic provision of resources - you need to factor in how the currently available resources aggregate.
• Consider how your cloud application is monitored. Does the cloud provider give you stats, and if so which; if not, what do you need to build in? Which stats do you need to ensure availability, to know when you need to increase resources - or reduce resources, since you are paying per resource, being able to dynamically deprovision when resources are idle becomes a potentially important option.
• It is important to assume that things can fail in the cloud. Design applications to expect and quickly recover from failures.

http://www.manageability.org/blog/stuff/patterns-for-infinite-scalability
Design Patterns for Almost-Infinite Scalability (Page last updated February 2007, Added 2011-04-27, Author Carlos E. Perez, Publisher manageability). Tips:

• Each entity which represents unique data should be uniquely identified.
• Each entity which represents unique data should be able to be processed independently.
• The application must tolerate message retries and out-of-order arrival of messages.
• Messages should be addressed to (uniquely identified) entities which can be located anywhere.
• Entities should know their history and not repeat processing (remember that a message has been previously processed).
• Don't assume the indices or references to entities can be updated atomically - assume these indices can become out of sync.
• Entities need to accept some level of uncertainty; messages that are sent are requests that may possibly be cancelled.
• Use fully decentralized techniques to remove scaling bottlenecks and single points of failure.
• The parts of system need to progress (asynchronously) under all circumstances.
• The system should be designed such that individual components can make decisions based on local information.
• Each individual component should be responsible for achieving its own consistency.
• Operations should be designed such that no or limited concurrency control is required.
• The system should consider the failure of components to be a normal mode of operation, and continue operation with no or minimal interruption.
• Abstractions used in the system should be of such granularity that parallelism can be used to improve performance; robustness of recovery; and the introduction of new nodes.
• Decompose into small well-understood building blocks. Do not try to provide a single service that does everything for every one, but instead build small components that can be used as building blocks for other services.
• Nodes in the system should be identical in terms of functionality, and require no or minimal node-specific configuration to function.
• The system should be made kept simple as possible.

Jack Shirazi Back to newsletter 125 contents