Building for Scale
Providing a centralized, integrated resource for information workers is a key aspect to SharePoint's popularity and cost effectiveness. SharePoint has a powerful infrastructure that integrates with line-of-business (LOB) systems. It runs multiple applications within a single shared infrastructure that provides a centralized place for information workers to access information and applications. Increasingly, SharePoint provides the infrastructure and services for both internal and external critical, high-volume Web sites. In these situations, performance and scale are important considerations. Neglecting them affects all applications that are running within the shared infrastructure. When building for scale, you need to consider both how to optimize your application and how to characterize your application behavior.
Scalability and Performance
Scalability and performance are often considered to be interchangeable. Although they are related, they are not the same thing. Performance measures how quickly your system responds to requests. Scale measures how much throughput your system can achieve, and throughput is the number of users that the application can handle simultaneously.
When you evaluate performance and scale, you should consider all components that comprise the system within the infrastructure. This includes Web front-end servers, application servers that host shared services providers, database servers, and network capacity. It is quite possible to make good decisions about your system's scalability that negatively impact its performance. For example, deploying services to multiple tiers will increase the scalability of a system, but it may degrade performance because it introduces additional network hops.
You can also make good decisions about performance that negatively impact the scalability of a system node. For example, if you cache a substantial amount of content in memory, users receive fast responses to their requests. However, using a cache decreases the amount of memory that is available to process requests. The result may be a reduction in the number of requests that you can simultaneously process on a Web front-end server.
Without performance and scale tests, it is not always obvious how a decision impacts a system. For example, in cases with computationally intensive applications, caching user information often results in improved overall throughput (and, therefore, scalability) by reducing computational bottlenecks. However, if too much information is cached, you may introduce a memory bottleneck in place of the computational bottleneck. The best way to determine the right balance is to test the application under realistic load conditions.
Not all decisions involve a tradeoff between performance and scalability. For example, optimizing the programming logic helps both. Such optimizations are always recommended, but they are best done after the system is complete. The effects of optimization are notoriously difficult to predict without load and stress testing, even when it is clearly necessary. A common example of where optimization is necessary is when you need to access a legacy line of business system that is slow to respond.
Some initial decisions about performance and scale can be made based on your experience with similar applications. This experience can help you to plan the application's architecture and design. However, after the system is developed, you must run performance and scalability tests to characterize and optimize tradeoffs between scale, performance, and cost. There are several ways to measure a system:
- Perform load and stress tests on the application in a realistic environment and under a realistic, simulated load.
- Stress test the individual components of the application by repeatedly running integration tests under load.
- Put the application into production and hope for the best. This is not a recommended strategy. The risks can be reduced by using hardware with greater capacities than what you think you require. This strategy depends on the patience of your users as you rework the application. A more moderate approach is to initially have a limited number of users. Depending on how critical the application is and the size of the user base, this may be a reasonable choice.
This topic discusses the lessons that were learned from load and stress testing the Partner Portal application. It does not provide a complete discussion of how to test all aspects of all SharePoint applications.
SharePoint supports many different types of functionality, and each type of functionality has different scalability and performance characteristics. For example, performance tuning a read-only Internet site is much different than performance tuning a collaboration site or an enterprise content management site. There is extensive guidance available on performance and capacity planning. For more information, see Plan for performance and capacity and Performance and Capacity Planning Resource Center for SharePoint Server 2007 on TechNet.
For general guidance on improving the performance and scalability of .NET Framework code, see Improving .NET Application Performance and Scalability on MSDN.