Partager via

ACE Team Performance Checklist

  • Article

The purpose of this checklist is to provide application teams with a list of common performance issues and or resolutions we come across when working on web applications. This checklist has been broken down by tier (Network, Web, SQL):

Network Performance Checks:

1) Minimize the network round trips between the client <> web server tier to sub 10 if possible. This will insure users with low bandwidth and or high latency connections the best chance of having an acceptable page load time / response time.

2) Minimize the data transferred between the client <> web server tier to sub 100-kb if possible. This will insure users with low bandwidth and or high latency connections the best chance of having an acceptable page load time / response time.

3) Insure the frame size of your data packets are full and as close to 1.5-kb as possible. This involves using Microsoft Network Monitor to analyze the HTTP response packets.

4) Use HTTP compression for static and basic text content where possible. Also, test and study the feasibility of compressing dynamic content.

5) Clean images and reduce the size as much as possible. Also, consider image clustering to combine images and reduce network round trips.

6) Remove white space and unneeded comments from your content to reduce the overall data transfer.

7) Limit and page data to the client to what the user actually requires. For example, 10-records at a time vs. 1,000 records at once.

8) Combine .css, .js, and other static content to a single file to limit the number of network round trips between the client <> web server.

9) Limit the number of methods called to a web service to 3 or less per user action. Each web service method will generate a minimum of 2 network round trips (usually 3 if Windows Integrated Auth is used).

10) Test using a software or hardware based WAN simulator for a selection of the connections and latency you plan to deploy on. At minimum, test with 300-kbps and 300-milliseconds latency broadband worst case and 56-kbps and 300-milliseconds latency for dialup.

Web Server Performance Checks:

1) Turn off/disable tracing and debug in the Web.config file. Also, verify tracing is disabled at the page directive level.

2)Test the benefit of implementing the Machine.config process model tweaks. These have been certified by Microsoft PAG and can be found at the following location:

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt17.asp -- refer to table 17.7

3) Limit the page load size to sub 100-kb. This can be achieved by streamlining content. HTTP compression will only assist in reducing the network transfer performance. Large content will impact CPU utilization, web server capacity, and response times.

4) Limit the size and use of _VIEWSTATE as much as possible. Large _VIEWSTATE tend to cause higher CPU utilization and larger page sizes which will impact response time and web server capacity. The “View State” section of the following Microsoft PAG article discusses these issues:

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt06.asp

5) Turn SSL off for objects that do not require encrypting (such as images). SSL will have a slight impact on CPU utilization and impact web server capacity.

6) Use ASP.NET Caching as much as possible. This will reduce the overhead of accessing the database tier for every execution. The “Using Cache” section of the following article by Microsoft’s PAG Team describes how to determine which objects to cache:

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt06.asp

7) Setup a consistent connection process throughout all the database calls which involves and explicitly closing connection objects. Doing this will avoid connection leaks.

SQL Server Performance Checks:

1) Disk subsystem should utilize RAID 1 + O and has many drives as financial feasible.

2) Utilize the smallest data types possible.

3) User SQL Profiler to measure any stored procedure or query’s taking + 1 second to process. Analyze and consider fixing these expensive calls.

4) Index tuning early and often to reduce the number of SQL reads and speed up query execution time. This will also reduce the time spent hitting the disk subsystem. The following articles details approaches to index tuning:

Index Tuning Wizard:

https://www.microsoft.com/technet/prodtechnol/sql/2000...

Index Tuning Info:

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/optimsql/odp_tun_1_6583.asp

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenethowto03.asp

5) Avoid stored procedure recompiles. The following articles detail the EventSubClass id’s and possible causes for sp recompiles.

SQL 7.0:

https://www.microsoft.com/technet/prodtechnol/sql/70...

SQL 2000:

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/sql_queryrecompilation.asp

SQL 2005: Not Available Yet

6) Limit the number of calls to SQL to sub 3 for a particular user action. Also, make sure calls are not redundant for a given user action.

7) Utilize hardware where financially feasible (including 64-bit). Make sure to thoroughly test before deploying to production.

8) Utilize memory and use the SQL AWE settings where possible (+4-gb). Make sure to thoroughly test before deploying to production.

9) Utilize software by upgrading to SQL 2005 (Yukon). Make sure to thoroughly test before deploying to production.

10) Plan and execute a data archiving strategy when feasible to minimize active database size and isolate fresh and old records.

Comments