Case study related to Performance and application diagonisis

Case Scenario: Choosing Where to Direct Output

You are working as an application developer in the Application Development department at A Datum Corporation. An application you helped develop has been deployed for about a month, and users have started complaining that performance is sluggish. The Database Administrator (DBA) of your company has been warning the Application Development department that the forecasted load for the new deployments would be too much for the current SQL Server database. Although there are noted hardware deficiencies, the DBA is sure that the many connection timeouts that are occuring are caused by connection leaks. The Network Administrator also had concerns that the Web servers were not going to be able to address the additional load.

The Corporate Vice President recently requested from the Application Development department a definitive list of everything that would be necessary to fix the problem "once and for all." He said that he's willing to purchase whatever resources are necessary, but any additional equipment that needs purchased that is not included in the memo will be purchased with your department's bonus pool money. He also indicated that he wants all the problems fixed, so any bugs that might be causing performance issues in addition to the database and Web server deficiencies had better be included in the memo. Your boss comes by your office and instructs you to write up the list. What do you do to solve this problem?

Image from book

Answers



To find out exactly what is needed, you will need to employ a strategy that encompasses the following tasks:
Rework the Data Access Layer components to include the use of performance counters. Use the .NET Data Provider for SQL Server. Track all the metrics related to Connection objects because there's a suspicion of a leak. Specifically, carefully watch the number of pooled connections and the number of reclaimed connections monitors.
On each of the Web components, add counters corresponding to ASP.NET. The Web server is a suspected cause of the performance issues, but it's not suspected to be as significant a cause as the database, so a small sample of counters should suffice.
Monitor the network utilization of your application by including the .NET CLR Networking performance counter.
On the client code, put similar measurement strategies in place. Keep track of memory utilization, network traffic, and file input/output.
Use the Windows event log to log any conditions where the application causes processor utilization to go above a given threshold.
Include assertions throughout your code to ensure that all your assumptions are correct.
Enable tracing, and insert copious code to track all instances of exceptions and items that caused them.