Best Practices for Performance
The following best practices, presented in no particular order, are recommended for creating high-performance applications.
Tune your software and hardware
Monitor application performance, especially throughput and latency, and tune your system parameters (software) and configuration (hardware) to eliminate or minimize bottlenecks using the following methodology:
- Determine the problem.
- Formulate a solution.
- Implement the solution.
- Analyze the results.
- Document everything.
For more information, see Performance Tuning Overview.
Reuse work by caching
Leverage the caching features of ASP.NET. One of the best ways to improve performance is by not doing the same work again and again. For more information, see Caching ASP.NET Pages.
Warn the user
If the user will experience a known delay when the application executes a particular feature, step, or function, set expectations by warning the user of the delay. Better yet, perform long-running code asynchronously and notify the user when processing is complete.
Tune your database
If your application uses a database, there are numerous steps you can take to remove bottlenecks when accessing and writing data:
- Identify potential indexes, but do not over index.
- If using SQL Server, use SQL Server's Profiler and Index Tuning Wizard.
- Monitor processor usage; desired range: 75-80% processor time.
- Analyze query plans using Query Analyzer to optimize queries.
- Use stored procedures to maximize performance.
- Normalize what you write a lot — write less data.
- De-normalize what you read a lot — read less data.
Read SQL Server 2000 Performance Tuning Technical Reference
Whalen, Edward, et al. SQL Server 2000 Performance Tuning Technical Reference. Redmond, WA: Microsoft Press, 2001.
This guide gives you the practical information you need to configure and tune a Microsoft SQL Server 2000 database for better, faster, more scalable solutions. The authors start with the basics and build upon them to teach the mechanics of performance tuning and how they affect the whole system. This book also shows how to optimize for the underlying operating system and hardware.
Partition large data tables
Use horizontal or vertical partitioning of large data tables to increase processing speed. Horizontal partitioning segments a table containing a large number of rows into multiple tables containing the same columns, but each table contains a subset of the data. For example, one table might contain all customers with last names beginning with the letters A through M and another table containing all customers with last names beginning with the letters N through Z. Vertical partitioning segments a table containing a large number of columns into multiple tables containing rows with equivalent unique identifiers. For example, one table might contain read-only data while the other table contains updateable data. In a large data environment, partitioning can extend across several database servers to further distribute the workload.
Stress test your application
The only way you can understand the behavior of your application is to put it under some load, even a moderate load with a test tool like the Web Application Stress Tool, and then experiment. You cannot adequately determine where bottlenecks exist in your application unless you test it under load. It is usually a better practice to stress test your application than it is to stress test your users. For details on the Web Application Stress Tool, see Performance Optimizing Tools.
Use transactions wisely
Transactions should be short-lived and incorporate only what is required. Distributed transactions require significant overhead that can adversely impact application performance. As such, they should only be used when truly necessary. For more information, see: Transaction Implementation in Duwamish 7.0 and Heterogeneous Distributed Transaction Implementation in Fitch and Mather 7.0.
Favor "chunky" versus "chatty" communication
Any cross-boundary communication that occurs between applications or processes adversely impacts performance. However, by minimizing the number of transitions that occur, you can minimize this impact. For example, it is more efficient to call a method requiring six input parameters than it is to set six properties and then call the method. This design pattern also promotes the use of a stateless business logic layer.
Use security wisely
Operating an e-commerce site does not necessitate the use of security on every page. Accessing pages using SSL/TLS incurs a significant amount of overhead since all communication is encrypted between the server and the client. Limit the use of secure communication to the pages that truly require it. If possible, serve those pages from a server dedicated to that purpose. For more information, see Securability.
Use of Web Services versus .NET Remoting
Creating a Web Service is not necessarily the best method for exposing functionality. In some environments, remoting across a TCP channel using a binary payload is more efficient than a Web Service using SOAP across HTTP. The decision to use Web Services is largely a question of interoperability and seldom a question of performance. For more information, see Distributed Application Communication.
Review the Best Practices for Scalability
Performance and scalability are closely entwined subjects. In addition to the practices listed here, review the Best Practices for Scalability.