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

http://highscalability.com/blog/2010/11/4/facebook-at-13-million-queries-per-second-recommends-minimiz.html
Facebook at 13 Million Queries Per Second Recommends: Minimize Request Variance (Page last updated November 2010, Added 2011-02-27, Author Todd Hoff, Publisher highscalability). Tips:

• It's important to be fast but not with high variance; slightly slower and consistent for all clicks is better.
• It can be okay for a query to be slow if it is always slow (users have adjusted their perceptions and find that adequate).
• Target edge cases to reduce variance: find out why the worst query is bad and fix that.
• You should monitor the production system.
• Target stalls - use periodic stack trace acquisition (poor man's profiling) to identify when threads are stalling from multi-threading issues.
• Systemwide concurrency conflicts encountered at Facebook were usually counter-intuitive "this can never happen" type problems: Extending a table locking the entire instance; Flushing dirty pages causing blocking; Statistics sampling in a subsystem.

http://blog.dynatrace.com/2010/11/05/how-we-improved-our-web-site-performance-rank-from-d-to-a/
How we improved our Web Site Performance Rank from D to A (Page last updated November 2010, Added 2011-02-27, Author Andreas Grabner, Publisher dynatrace). Tips:

• Merge images to reduce network roundtrips (technique is called using sprites) - then the various images used for display are decomposed from the merged image.
• Domain sharding (spreading resources across multiple domains) worksaround browser limitations on the number of connections available per domain.
• Cache resources in the browser wherever possible - infrequently changed resources can still be cached indefinitely by changing the name of the resource if you want to force a new load.
• Outsourcing to a content delivery network is useful for speeding up delivery of large static resources as they can be much closer to the end-user than your servers.
• https is much slower than http - so don't force users to access an https where the security is not required (i.e. by default your resources might just be referring to the relative URL and this would be https if the user was logged in).

http://blog.yohanliyanage.com/2010/10/ktjs-3-soft-weak-phantom-references/
Know the JVM Series - When Weaker is Better: Understanding Soft, Weak and Phantom References (Page last updated November 2010, Added 2011-02-27, Author Yohan Liyanage, Publisher yohanliyanage). Tips:

• An unbounded cache using strong references with no deletion policy is a memory leak.
• A bounded cache using strong references with a deletion policy (e.g. oldest or least recently used) cannot automatically take advantage of extra available memory; nor can it respond to low memory situations.
• If you hold a weak reference (e.g. via WeakReference) to a particular instance and it has no strong references to it, then the JVM can sweep it out of the memory if it needs to.
• WeakReferences can be freed in any GC cycle regardless of whether there is available memory; SoftReferences can be similarly freed but the JVM is encouraged not to free them unless memory is low; PhantomReferences are freeable as soon as their referent is not referred to by any other type of reference (strong, weak, and soft).
• PhantomReferences are useful for finalization code for objects being garbage collected.

http://www.ovaistariq.net/404/mysql-paginated-displays-how-to-kill-performance-vs-how-to-improve-performance/
MySQL Paginated displays - How to kill performance vs How to improve performance! (Page last updated November 2010, Added 2011-02-27, Author Ovais Tariq, Publisher ovaistariq). Tips:

• Pagination (showing only some of the results, a "pagefull", at a time) is an important performance technique.
• The largest sites (Google, Facebook, Yahoo) implement pagination with specific restrictions: they do not show an accurate count of total available results, instead they show an estimate or no count; they do not implement a "go to last" option; they only allow navigation through a limited set of pages (next and last in the tightest case).
• Pagination using an estimate of the total available results rather than an actual count is more efficient than giving an accurate count, as it avoids the extra counting required (and an extra query).

http://assets.en.oreilly.com/1/event/22/High%20Performance,%20Low%20Cost,%20and%20Strong%20Security_%20Pick%20Any%20Three%20Presentation.pdf
Low Cost, High Performance, Strong Security: Pick Any Three (Page last updated November 2010, Added 2011-02-27, Author Chris Palmer, Publisher oreilly). Tips:

• Strategy: Biggest Performance Impact is to Reduce the Number of HTTP Requests
• HTTP has no security guarantees at all. None. Zip. De nada. Use Https. It can be made performant for all but the most low latency requirements. If your target is 98% of responses should be <5 seconds, HTTPS can achieve that. If your requirement is 99% of responses < 400ms, HTTPS probably can't achieve that. Very few sites really need the latter.
• use HTTP/1.1 persistent connections, and reduce the number of requests/responses
• turn on TLS session resumption
• HTTPS handshake latency is the major cost of HTTPS, amortized by resuming TLS sessions and maintaining the HTTPS connection
• The major improvement in HTTPS (and HTTP) latencies is to reduce the number of requests made from the browser (i.e. by redesigning the page to reduce this)
• Most of web page performance is affected by the user interface design and development (page design).
• DON'T have giant cookies, giant request parameters
• DO compress responses (gzip, deflate).
• DO minify HTML, CSS, and JS.
• DO use sprites.
• DO compress images at the right compression level
• DO use the right compression algorithm for the job.
• DO maximize caching.
• DO enable TLS session resumption on the TLS server
• Present people relevant information, allowing them to make good choices at the right time without distractions
• Profiling tools httprof (http://code.google.com/p/httprof); YSlow and HTTPFox (Firefox plugins); WebScarab (https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project); Wireshark.

http://perspectives.mvdirona.com/2010/11/29/AvailabilityInGloballyDistributedStorageSystems.aspx
Availability in Globally Distributed Storage Systems (Page last updated November 2010, Added 2011-02-27, Author James Hamilton, Publisher perspectives). Tips:

• Disk failures are often the #1 or #2 (after memory) failing component in a storage system.
• The assumption of component failure independence is violated by every real-world system of any complexity . Things rarely fail in isolation, and the knock-on effects of failure are unpredictable. The only way to handle this is to build in redundancy.
• Replicating data across multiple datacenters greatly improves availability because it protects against correlated failures.
• Two way redundancy in two different datacenters is considerably more durable than 4 way redundancy in a single datacenter.
• Correlation among node failures dwarfs all other contributions to unavailability in production environments.
• Disk failures can result in permanent data loss but transitory node failures account for the majority of unavailability.

Jack Shirazi Back to newsletter 123 contents