Andreas Grabner About the Author

Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi

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

For a recent edition of the Swiss Computerworld Magazine we listed our Top 10 Performance Problems as we have seen them over the years when working with our clients. I hope this list is enlightening – and I’ve included follow-up links to the blogs to help better understand how to solve these problems:

#1: Too Many Database Calls

The problem we see the most are too many database query per request/transaction. There are 3 specific phenomena to witness

  1. More data is requested is than actually required in the context of the current transaction, e.g.: requesting all account information instead of those that we need to display on the current screen.
  2. The same data is requested multiple times. This usually happens when different components involved in the same transaction act independently from one another and each requests the same set of data. It is unknown what type of data has already been loaded in the current context so we end up with the same queries multiple times.
  3. Multiple queries are executed to retrieve a certain set of data. This is often a result of not taken full advantage of complex SQL statements or stored procedures to retrieve the data in one batch.

Further Reading: Blog on Linq2Sql Performance Issues on DatabaseVideo on Performance Anti-Patterns

#2: Synchronized to Death

There is no question that synchronization is necessary to protect shared data in an application. Too often developers make the mistake to over-synchronize, e.g.: excessively-large code sequences are synchronized. Under low load (on the local developers workstation) performance won’t be a problem. In a high-load or production environment over-synchronization results in severe performance and scalability problems.

Further Reading: How to identify synchronization problems under load

#3: Too chatty on the remoting channels

Many libraries out there make remote communication seem like a piece of cake. There is hardly any difference for the developer to call a local vs. remote method. The lack of understanding of what is really going on under the remoting-hood makes people forget about things like latency, serialization, network traffic and memory usage that come with every remoting call. The easy way of using these technologies results in too many calls across these remoting boundaries and in the end causes performance and scalability problems.

Further Reading: Performance Considerations in Distributed Applications

#4: Wrong usage of O/R-Mappers

Object-Relational Mappers take a big burden off developers’ shoulders – loading and persisting objects in the database. As with any framework there usually are many configuration options to optimize the usage of the O/R Mapper for current application use cases. Faulty settings and incorrect usage of the framework itself too often results in unexpected performance and scalability problems within these frameworks. Make sure you make yourself familiar with all options and learn about the internals of these libraries that you rely on.

Further Reads: Understanding Hibernate Session Cache, Understanding the Query Cache, Understanding the Second Level Cache

#5: Memory Leaks

Managed runtime environments such as Java and .NET have the advantage of helping with memory management by offering Garbage Collectors. A GC, however, does not prevent memory leaks. Objects that are “forgotten” will stick around in memory and ultimately lead to a memory leak that may cause an OutOfMemoryException. It is important to release object references as soon as they are no longer needed.

Further Read: Understanding and finding Memory Leaks

#6: Problematic 3rd Party Code/Components

Nobody is writing all of the functionality of a new application on their own. We use existing 3rd party libraries to speed up our development process. Not only do we speed up our output – but we also increase performance risks introduced by these components. Even though most frameworks are well documented and have been thoroughly tested, there is no guarantee that these frameworks run as expected in every use case they are included. 3rd party code is often used incorrectly or in ways that have not been tested. It is therefore important to make an in-depth check of every framework before introducing it into your code.

Further Read: Top SharePoint Performance Mistakes

#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. A good example: database connections that are kept open for too long. Connections must only be used for the time period they are really needed, e.g.: for a query – and then returned to the connection pool. We often see that connections are requested early on in the request handler and are not released until the very end which leads to a classic bottleneck situation.

Further Read: Resource Leak detection in .NET Applications

#8: Bloated web frontends

Thanks to high-speed web access many users have a better end-user experience in the World Wide Web. The downside of this trend is that many applications get packed with too much stuff – they become bloated – which ultimately leads to bad browsing behavior. Particularly  users that do not yet have high-speed internet access suffer the most. Too many images that are too large; failure to use or incorrect usage of the browser cache; or overly-aggressive usage of JavaScript/AJAX – all result in performance problems in the browser. Following the existing Best Practices on Web Site Performance Optimization can solve most of these problems:

Further Reads: How Better Caching would help speed up Frankfurt Airport Web Site, Best Practices on Web Performance Optimization

#9: Wrong Cache Strategy leads to excessive Garbage Collection

Caching objects in memory to avoid constant roundtrips to the database is one way to boost performance. Caching too many objects – or objects that are hardly ever used quickly changes the advantage of caching into a disadvantage due to higher memory usage and increased GC activity. Before implementing a caching strategy you have to figure out which objects to cache and which objects not to cache in order to avoid these types of performance and scalability problems:

Further Reads: Java Memory Problems, Identify GC Bottlenecks in Distributed Applications

#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. Full test coverage – functional as well as load and performance coverage – will uncover most of these problems early on before they become real problems for real users.

Further Reads: Tracing Intermittent Errors by Lucy Monahan from Novell, How to find invisible performance problems

(Bonus Problem) #11: Expensive Serialization

With remoting communication – such as Web Services, RMI or WCF – objects need to serialized by the caller in order to be transferred over the network. The callee on the other side needs to de-serialize the object before it can be used. Transformation therefore happens on both sides of the call resulting in some overhead while doing so. It is important to understand what type of serialization is required by both ends and what the optimal choice of serialization and transport type is. Different types of serialization have a different impact on performance, scalability, memory usage and network traffic.

Further Read: Performance Considerations in Distributed Applications

Learning from Zappos, Monster & Co

We often ask our customers to tell their stories in a webinar. They share their challenges with performance management, how they overcame those challenges, and, the Best Practices they’ve developed from those experiences. I recommend listening in to the stories from Zappos, Monster, Insight, Novell, PeopleClick, SmithMicro or Thomson Reuters. You can listen to to these recorded webinars and learn to what they have to say

About The Author
Andreas Grabner
Andreas Grabner Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi


  1. excellent compilation!

  2. #4 & #6 are your worst enemy in my opinion and the reason why you should use your own framework… who better than you to know how best to use it?

    Personally I don’t cache on the database side but I do cache composite outputs and for most purposes that is sufficient – provided the framework in question isn’t bloated in the first place (sounds like Zend Framework come to mind).

    Good advice all round though so well done.

  3. Well, you can’t redevelop everything on your own. Thats simply not productive.
    So it definately is important to use 3rd party software CORRECTLY. Thanks for the article!

  4. Nobody ever gives credence to #11 though its a huge problem. I work at a company where upper management decided to replace all direct database interaction with SOAP based web services. They didn’t give any credence to the additional processing required: Retrieve information from the database, build the information into a SOAP request, transmit over the network, parse through the SOAP on a proxy server or client app, deliver the result. That might sound benign but proper XML encoding bloats the message (as in you need an open and close tag for every value, additional text to describe namespaces and attributes, etc…), meaning longer transmission times. As a result of our effort, there’s noticeable lag across all projects built according to this infrastructure.

    I wish you’d put this out months ago so I could cite your logic in meetings. Might have avoided this mess.

  5. @Chris:you are totally right.SOAP sounds easy and has it strengths-but you have to look under the covers to find out whether it really makes sense to go down that route.There are more lightweight alternatives to SOAP/XML such as e.g.: JSON.
    @Rest:glad you like this compilation. Check out the rest of the blog – there is lots of stuff on both server-side as well as client-side performance problems.

  6. Hi, I want to translate this Article to Portuguese. Do you authorize this translation?


    • Hi Alexandre
      Go ahead and translate. If you got it posted somewhere it would be great if you could post a link on this blog so that more people can take advantage of your translation

  7. I don’t cache on the database side but I do cache composite outputs and for most purposes that is sufficient – provided the framework in question isn’t bloated in the first place (sounds like Zend Framework )for me..

  8. I always try to look at things from the customer’s point of view, and from that perspective, I may say that anyone who tell that your post is not great and very informative is wrong. Thanks for putting all this together.

  9. Really a great job again and this post is also new information for me and now i am going to share with my friends.

  10. Top Web Design Companies says:

    I don’t accumulation on the database ancillary but I do accumulation blended outputs and for best purposes that is acceptable – provided the framework in catechism isn’t aggrandized in the aboriginal abode (sounds like Zend Framework )for me. Thanks for sharing this information.

Speak Your Mind


Do the math so we know you are human *