Guidelines on Post-Production Performance Issues & Resolutions

There is no such thing as bug-free software!

Although nice to think about, bug-free software seems to be a tomorrow that will never come. Problems can come from anywhere. There’s always a little chance of error when it comes to speed and performance in a web application, particularly when it involves customers and revenue. Though it is inevitable to evade any errors, we can definitely prevent them with some proactive actions like post-production performance testing. Some of the most common issues identified are:

  • Long user response time
  • Long server response time
  • Memory leaks
  • High CPU usage
  • Length queues for requests
  • HTTP errors
  • Pages not available

It is rightly said that prevention is better than cure. As an experienced software testing company, we thought of drafting guidelines on some of the most common performance issues one can encounter and how to resolve them.

Poorly Written Code:

Poorly written code can cause memory leaks and application deadlocks. Sometimes the old version of a software or integrated legacy system can also drag performance down.

Solution: Make sure an application has passed through white box testing, teams are using all the tools at their disposal – from automated tools like profilers to best programming practices like code reviews.

Un-Optimized Databases:

The production environment can be destroyed by an un-optimized database output. Missing indexes also slow down the performance of SQL queries.

Solution: Make sure the developer has used the scripts and file statistics to check for any inefficient queries. 

DNS, Firewall, and Network Connectivity:

The DNS queries take the majority of web traffic. Sometimes outside visitors also face the problem of opening the site and resulting errors, 404, and incorrect pathway.

Solution: Use DNS monitoring safeguards to pinpoint problems at hand. Also, revise switches, check VLAN tags, and distribute tasks between servers.

Slow 3rd Party Search Service: 

Sometimes 3rd party tools slow down and get out of control. It’s hard to determine whether the problem is on our side or that of the third-party user. If you decide to continue using the third-party service, look at making some design changes to protect your site from at least some of the effects of a third-party service issue.

Solution: Make sure that your off-service provider guarantees performance.

Extreme XML Processing:

If data is too long to process then XML processing can be a long process after fetching data from the database and it takes so much time and resulting in the slowness of the server and creating a bad effect on the performance of the application.

Solution: Make sure the server configuration is also high so that multiple requests and responses can be handled in a minimum amount of time.

Excessive SQL Queries:

SQL query requests come from an application and are fulfilled by a database that sometimes application throws so many requests at a time. The stack will create on the application pool and as per request priority, the database gives output to the application. It may be possible that so many client requests are on the application pool and it takes a too long time to render the request of the application and resulting in the slowness of the server.

Solution: Server configuration should be high so that so many Queries can be handled in less amount of time.

Mail Server Connectivity:

The application uses the Mail server for communication. Sometimes it takes a long time to connect the mail server and resulting in slowness.

Solution: We can use continuous ingression tools available in the market like, “New Relic” (End-to-end transaction tracing, code-level visibility, and Key transaction).

Below are a Few Points for Resolution of this Post Production Performance Issue:


Web Application Performance Tuning

  1. Turn off Tracing unless required
  2. Turn off Session State, if not required
  3. Disable View State of a page if possible
  4. Set debug=false in web.config
  5. Avoid Response
  6. Use the String builder to concatenate string
  7. Avoid throwing exceptions
  8. Use Finally Method to kill resources
  9. Use Client Side Scripts for validations
  10. Avoid unnecessary round trips to the server
  11. Use Page.ISPostBack
  12. Include Return Statements within the function/method
  13. Use “ArrayLists” in place of arrays
  14. Avoid unnecessary indirection

Tips for Database Operations

  1. Return multiple result sets
  2. Connection Pooling and Object Pooling
  3. Use SqlDataReader Instead of Dataset wherever it is possible
  4. Keep your datasets lean
  5. Avoid inefficient queries
  6. Unnecessary round trips
  7. Too many open connections
  8. Avoid transaction misuse
  9. Avoid over normalized tables
  10. Reduce serialization
  11. Do not use command builder at run time
  12. Use stored procedures whenever possible
  13. Avoid auto-generated commands


Web applications are becoming complex day by day and at the same time, the identification of their performance bottlenecks is becoming a tough task. Various factors contribute to the performance issues and knowledge of those issues & their symptoms is mandatory to rectify the performance bottlenecks. Web server, application server, database server hardware, software, and design along with network configurations can be major contributors to performance bottlenecks. Moreover, client-side design and third-party components can also affect web application performance. Knowledge of performance testing and a complete list of symptoms of all potential problem areas will help in identifying the root cause and its remedy.

Vishal Shah

Vishal Shah has an extensive understanding of multiple application development frameworks and holds an upper hand with newer trends in order to strive and thrive in the dynamic market. He has nurtured his managerial growth in both technical and business aspects and gives his expertise through his blog posts.

Related Service

Know more about Software Testing services

Learn more

Want to Hire Skilled Developers?


    • Leave a message...