Back to newsletter 134 contents

http://www.theserverside.com/feature/Practical-Challenges-of-Profiler-Integration-with-Java-J2EE-Applications
Practical challenges of profiler integration with Java/J2EE applications (Page last updated October 2011, Added 2012-01-30, Author Madhu Tanikella, Publisher theserverside). Tips:

• Profiling is analyzing and understanding an application in terms of the time spent in various methods, calls, locks, contention and the memory usage of the code.
• CPU Profiling mainly focuses on identifying high latency methods; it can use elapsed Time or CPU Time to find how much time methods are taking, where Elapsed Time = CPU Time + Wait Time (from DISK I/O + Network I/O + Lock Acquisition + Context Scheduling).
• When using CPU time for profiling, it does not show the time spent in database execution because in the client that is waiting for Network I/O.
• Memory profiling analyzes object creation allowing you to optimize the memory footprint and eliminate memory leaks.
• Profilers are usually configured with an agent/probe which runs in the server and collects metrics; and a console which gathers the metrics from agents/probes, and displays them.
• XX flags which could affect the ability of a JVM to run with a profiling agent include: -XX:+AggressiveOpts (as this is experimental and changes, it could interfere); -XX:-EliminateZeroing (could cause unexpected behaviour as it violates Java spec); -XX:-ExtendedDTraceProbes (this is already a profiling agent, so could interfere with another); -Xrunhprof[:options] (this is already a profiling agent, so could interfere with another).
• Profilers affect the timing of what they measure, and so the amount of code they affect should be minimized for effective profiling.
• Profilers can affect the stability of the application and the JVM. This is usually acceptable in development, but not in production. You need to ensure you configure any production profiler so that only features that do not impact stability are used.

http://srinathsview.blogspot.com/2011/10/list-of-known-scalable-architecture.html
List of Known Scalable Architecture Templates (Page last updated October 2011, Added 2012-01-30, Author Srinath Perera, Publisher srinathsview). Tips:

• There are only 3 way to scale: distributing work, caching, and asynchronous processing.
• One scalable architecture is: A set of shared-nothing workers, fronted by load balancers that distribute requests across the workers.
• One scalable architecture is: A set of workers using shared scalable storage, fronted by load balancers that distribute requests across the workers. The storage scalability is the limiting factor.
• One scalable architecture is: A Peer-to-peer architecture (peers are equally privileged, equipotent participants), though these can suffer from latency issues if not carefully managed
• One scalable architecture is: A Distributed set of queues with hierarchies and priority support
• One scalable architecture is: Publish/Subscribe
• One scalable architecture is: Based on Gossip and Nature-inspired Architectures - partially randomly distributed rule-based processing
• One scalable architecture is: Map-Reduce Data flows
• One scalable architecture is: Tree of responsibility - a recursive breakdown of tasks
• One scalable architecture is: Stream processing
• One scalable architecture is: Scalable Storage
• A scalability killer is global coordination - any kind of global coordination will limit the scalability of the architecture. Local coordination should be targeted for scalability.

http://highscalability.com/blog/2011/9/23/the-real-news-is-not-that-facebook-serves-up-1-trillion-page.html
The Real News is Not that Facebook Serves Up 1 Trillion Pages a Month... (Page last updated September 2011, Added 2012-01-30, Author Lori MacVittie, Publisher highscalability). Tips:

• Facebook handles more than 100,000 requests per second consistent load - most successful DDOS attacks use less traffic than this! (actually probably handles several million requests per second).
• The only sensible way to deal with arbitrarily increasing loads is to spread across arbitrarily many machines.
• Horizontal scalability is enabled via load balancing. The load balancer is an intelligent routing balancer that can examine a URI and make routing and multiplexing decisions based on that - as well as protect against denial of service attacks.
• Separate "write" databases from "read" enhanced the scalability of the application architecture.
• Modern applications must leverage both modern application scalability patterns as well as infrastructure scalability patterns.

http://blog.dynatrace.com/2011/11/23/top-8-performance-problems-on-top-50-retail-sites-before-black-friday/
Top 8 Performance Problems on Top 50 Retail Sites before Black Friday (Page last updated November 2011, Added 2012-01-30, Author Andreas Grabner, Publisher dynatrace). Tips:

• Excessive use of HTTP Redirects is a common cause of bad performance.
• JavaScript onLoad time (and required CSS file downloads) blocks the browser until completed, causing a perceived reduction in performance.
• Some complex CSS, Javascript and plugin operations can take a long time in certain browsers, causing bad performance.
• Pages with large content can lead to long load times.
• Browser side caching is an option to cache mainly static content on the browser to improve page load time for revisiting users.
• Reducing resources is a general best practice which will lower the number of roundtrips and also wait time per domain.
• Too many server-side requests and long server processing times will cause long response times to browser so giving slow performance

http://www.jperla.com/blog/post/how-to-launch-in-a-month-scale-to-a-million-users
How to launch in a month, scale to a million users (Page last updated September 2011, Added 2012-01-30, Author Joseph Perla, Publisher jperla). Tips:

• Build automated tests for all external facing APIs; keep the APIs stable (put enhancements that require API changes into new APIs and retain the old APIs); use the APIs internally, don't shortcut to use "internal" methods.
• Keep the client fast, and leverage it's computing power.
• Provide external APIs with options that can minimize the data returned.
• Design with upgrading any opart in mind; Implement and re-implement using what you learn from earlier implementations.
• Use known or accessible information to speed up information acquisition by short-circuiting lookups where feasible.
• Provide specialised optimal procedures for the normal case, and fall back to the less optimal general procedure for other cases.
• Split resources in a fixed way - e.g. writes take longer than reads, split these so they don't impact each other.
• Cache answers to expensive computations.
• Use simple brute force as a first pass as this may be perfectly okay for most cases - there are many ways to optimize a system to improve performance, but they come at the cost of decreasing modularity, making more assumptions and costly developer time.
• Compute in background when possible, queueing tasks and sending results asynchronously.

http://vanillajava.blogspot.com/2011/11/why-concurency-examples-are-confusing.html
Why Concurrency examples are confusing (Page last updated November 2011, Added 2012-01-30, Author Peter Lawrey, Publisher vanillajava). Tips:

• Simple functions are often more efficient single threaded than multi-threaded because of the overhead in handling the concurrency (and the concurrent version is more confusing too).
• synchronized is marginally faster than explicitly locking when the locks are un-contended.
• A global lock is faster than per-object locks, but produces more contention. The tradeoff in a simple account trade example was at 7 concurrent threads (below 7 concurrent threads, the global lock was more efficient).
• When multi-threading, you should take a single-threaded, lock free implementation as a base line to compare against. If the additional complexity doesn't produce a sufficient speed advantage, don't multi-thread.

Jack Shirazi Back to newsletter 134 contents