« Hot Scalability Links for July 17, 2010 | Main | Sponsored Post: VoltDB and Digg are Hiring »

DynaTrace's Top 10 Performance Problems taken from Zappos, Monster, Thomson and Co

DynaTrace in Top 10 Performance Problems taken from Zappos, Monster, Thomson and Co, has provided a useful compilation of performance problems, with potential solutions, that they've found while working with their clients. 

  1. Too Many Database Calls -  too many database query per request/transaction.
  2. Synchronized to Death - in a high-load or production environment over-synchronization results in severe performance and scalability problems.
  3. Too chatty on the remoting channels - too many calls across these remoting boundaries and in the end causes performance and scalability problems.
  4. Wrong usage of O/R-Mappers - incorrect usage of the framework itself too often results in unexpected performance and scalability problems within these frameworks.
  5. Memory Leaks - GC does not prevent memory leaks, it is important to release object references as soon as they are no longer needed.
  6. Problematic 3rd Party Code/Components - check of every framework before introducing it into your code.
  7. Wasteful handling of scarce resources - Resources such as memory, CPU, I/O or the database are scarce. Wasteful handling of these resources results in lack of access to these resources by others and ultimately leads to performance and scalability issues.
  8. Bloated web frontends - many applications get packed with too much stuff.
  9. Wrong Cache Strategy leads to excessive Garbage Collection - Before implementing a caching strategy you have to figure out which objects to cache and which objects not to cache.
  10. Intermittent Problems  - Intermittent problems are hard to find. These are usually problems that occur with specific input parameters or only happen under certain load conditions. 
  11. (Bonus Problem) Expensive Serialization. Different types of serialization have a different impact on performance, scalability, memory usage and network traffic.

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments (5)

Excellent list. Thanks for bringing it to my attention. ;)

July 14, 2010 | Unregistered CommenterJeff Darcy

One pattern that I'd add that cuts across these is a failure to properly identify critical performance paths. Many systems, for example, have a fairly tight API that represents 99% of the critical traffic (or more) and is small enough that it could be hand-tuned, but its built using the same framework and design practices that are used on the associated public website. Or the reporting engine. Or whatever.

Figure out what's really important and tune the ___ out of it... and be willing to use whatever time-saving inefficient framework you can to speed development on the remainder of the system if needed to make sure that you've got the time to spend where you have to. If a complex admin-facing web-portal leaks a little memory for each user that's reclaimed when their session expires, but it represents .001% of your traffic, it probably doesn't matter - and you should happily trade that "problem" for the chance to hand-tweak a SQL statement that's called 1,000 times a second.

July 14, 2010 | Unregistered CommenterRichard

I love your website! did you create this yourself or did you outsource it? Im looking for a blog design thats similar so thats the only reason I’m asking. Either way keep up the nice work I was impressed with your content really..

July 14, 2010 | Unregistered CommenterKpss

Reasons 2-5 can be summarized as: Using Java.


July 15, 2010 | Unregistered CommenterAnonymous

I don't have big website , but i love your blog :).
Learning so much about scalability

July 16, 2010 | Unregistered CommenterIwan BK

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>