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.

Comments

[Jeff Darcy]

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

[Richard]

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.

[Kpss]

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..

[Anonymous]

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

;)

[Iwan BK]

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