During development normally the thought about performance of the application does not come to mind. That is because you test your code in your own desktop and if everything works functionally you move on. Some of the performance problems might show up during the load/stress test of the application by the quality team. But one problem that can really take a lot of time to find out is a memory leak. This is very common in web applications if not been thought and tested out before hand. A web application receives multiple requests hitting the server. Each request is treated as a thread that spawns a process in the web server and loads the appropriate objects from the application. When the response is sent, the objects loaded have to be released to clear up the memory.

Think about this, a web application continuously will keep receiving requests as long as the web server is up and running. If after a request is complete a used by the request doesn’t get cleared then for every request there will be an object residing in the memory till the web server’s life goes down. Now how can this happen? Why doesn’t the web server or the component that is responsible for handling that particular technology/programming model take care of it? The answer is it does but if you do not clean the object references and/or keep the scope of the objects in such a way that it is marked for removal once the execution comes out of that scope, the component that takes care of removing the object will think the object is still in use and will not remove it from memory. So if your web application project has gone live and after some time if you are hitting the memory limits then your application might be leaking. So it is imperative that the application be tested for memory leaks beforehand. There are tools that can determine if there is a memory leak in your application. Refer “Memory Leaks” in wikipedia that has detailed explanation as well as some good pointers.