To identify performance bottlenecks try the following:
Use standard Window instrumentation technologies such as Perfmon, SQL Server Profiler and Task Manager to identify the location of the most significant bottlenecks. In complex cases specialist profiling tools could be employed such as the ANTS Performance Profiler from Redgate.
Add instrumentation functionality into the application.
Logging. Extensive logging capabilities which are configurable and highly targetable. It would be possible to set difference logging levels for specific modules and even different users. This would enable logging to be utilised in a production environment without prohibitive performance penalties. In my current role we injected JavaScript code into each page. This made it possible to determine what percentage of the total round-trip time was due to internet connectivity issues and what percentage of the time was due to server activity. Microsoft has recently released a Power Tool called Microsoft Visual Studio AJAX Profiling Extensions that provide similar (and much more extensive!) functionality.
Performance Counters. In my current role we built application specific performance counters which could be used to monitor the performance of the production environment in real-time.
Take a copy of the application and set up a testing environment to see how the application performs under heavy load.
Examine the business logic to identify poor coding techniques such as repeatedly creating and destroying objects when a single instance could be cached and reused, excessive database access etc.
Typical causes of performance bottlenecks are:
Poorly designed SQL queries that hold database locks for extended periods of time, include a high number of joins etc.
Very ‘chatty’ data access, where business logic makes a high number of very expensive database calls.
Too many server post backs.
Excessive use of view state within ASP.NET pages.
Lack of attention to performance and scalability requirements during the design phase.
To fix performance bottlenecks try the following:
Reduce the number of complete screen refreshes (or server round trips) by using Ajax-based technologies to only update the area of the screen that has actually changed.
Reduce the amount of database access by re-engineering the application to move logic into the database. Normally application logic should only exist within the business layer, but under exceptional circumstances it can move into the database.
Reduce the amount of database access by caching data within the business layer using a distributed caching technology.
Ensure data is accessed using stored procedures whenever possible to increase performance by enabling SQL Server to cache execution plans.
Implement support for a flexible deployment model so that the application can run within a web farm environment. This will involve building a state-less application layer to avoid so-called ‘sticky sessions’. This will enable a load balancer freedom to efficiently distribute individual requests across the entire web farm.
Promote the use of performance and scalability best practices via coding standards, code generation etc.
You must log in to post a comment.