The architecture of your site can have a substantial impact on the performance of your pages. However, it is worth noting again that this is not the best place to start your performance planning. Only after you have optimized all the other areas of your design should you then consider how to improve the performance of your deployment. This game plan will result in the best-performing site with the least amount of hardware and the simplest deployment architecture.
One of the most obvious ways to increase the performance of your CMS deployment is to use dedicated hardware. Although you could run other applications, such as SQL Server, on the same machine as the CMS server, this is clearly not the best strategy.
Another point to consider is that having other applications running on the CMS server will make your performance testing much more complicated. As the various applications compete for resources, there could be a number of permutations of resource usage that are difficult to diagnose. With a dedicated CMS server and a dedicated SQL server, it is much easier to get reliable performance numbers.
You may not feel that it is important for your site to scale, but will this be true in the future? Someday, you may need the added flexibility that performance scaling offers. "Scaling up" is the process of maintaining performance as you increase the number of CPUs within your CMS server. In the long run, scaling up could save you money on hardware. Rather than adding another machine, you could save time and money by adding another processor to your CMS server.
However, it is important to realize that adding processors will not result in a linear increase in performance. If you go from one processor to two, you might not see a 100% increase in performance. But you may not require that sort of increase. If you are just under your performance goals, adding an extra processor may be a good solution.
Figure 34-13 illustrates the scale-up results for WoodgroveNet. The numbers have been adjusted so that both cached and uncached results start with a value of one. The actual throughput for cached pages on one processor was over seven times greater than for uncached pages. The throughput for eight processors showed a difference of almost five times.
Figure 34-13. CMS scale-up results
"Scaling out" is the process of maintaining performance across a server farm. CMS servers support this type of clustering; because of this, CMS is able to run extremely large Web sites. For example, Microsoft has recently deployed dynamic CMS sites on Microsoft.com. To see an example, you can navigate to http://www.microsoft.com/cmserver. This is the first of many scheduled CMS deployments across Microsoft.com. It would certainly not be possible to run a site that gets as much traffic as Microsoft.com without using a scale-out model. Even a static Web site would not be able to handle sites of this size if they had to run on a single server.
Clustering is achieved using load balancing. As client requests hit the sites, they first go to the load balancer and then are routed to the Web server that is best able to serve the request. There are two flavors of load balancing: software load balancing and hardware load balancing. Software load balancing, such as Windows Network Load Balancer, is often the cheaper of the two options. However, hardware load balancing is able to handle a much greater load. Make sure that you investigate your needs before you invest in either option. Figure 34-14 shows the benefits of scaling a CMS site across many machines.
Figure 34-14. CMS scale-out results
Note that deploying CMS servers in a cluster is also important in cases where failover and reliability are among the top priorities. If your Web site must be running all the time, then you will need to have at least two CMS clusters. Refer to the Microsoft deployment white paper for more information.
It is unlikely that most sites will need to worry about partitioning. However, if your performance requirements cannot be met by scaling up and scaling out, you will need to partition your site over multiple CMS server clusters.
Partitioning a site can provide many performance benefits. Obviously, a smaller working set means that more pages in the set can be cached. Also, the principle of dedicated hardware applies because you are dedicating hardware not only to CMS but to specific parts of your site.
A candidate for site partitioning would be one with extremely high traffic and a very large working set. Microsoft points out that a server using the maximum of 4GB of memory might be able to cache a working set of 10,000 pages. If your site happens to have a working set of 20,000 pages, then you may need to divide your site into two clusters. Each cluster would contain half of the Web site pages. Keep in mind that this site would likely have hundreds of thousands of pages and would constitute one of the largest Web sites in the world.
Authoring and Performance
CMS servers are most efficient when many read and few write operations are occurring. This is, of course, the most popular usage pattern for any Web site. However, you may find that authoring on your CMS server is affecting performance to an unacceptable degree. The best possible deployment scenario is to separate your CMS servers into an authoring environment, a test environment, and a production environment. For added security, the production tier is generally the only one that is accessible across the Internet.
Having a dedicated authoring environment allows you to bundle your content updates into regular deployment packages and minimizes the impact to the production tier. The most obvious example of this is the many caches that are affected by authoring. When CMS authors change content, they are invalidating the many caches on the server. This is particularly important for coarse caches such as the ASP.NET output cache.
Keeping in mind the impact to caching, you can imagine how writing to the CMS server can substantially impact your performance. Not only are you performing writes to the database, but then this data must be written into the many caches on the system.
Even so, it is quite possible that authoring against your production tier will still leave you within acceptable performance limits. There are administrators running large CMS sites who are comfortable with the performance and security implications of authoring on their production tier. One of the main factors in this decision is how important it is to have updates go live immediately. News sites, for example, may find that their business needs conflict with their desire to improve performance by caching content. They may accept that their authors will be constantly updating and creating pages. But this is their business and therefore is their most important consideration.
Authentication is the action of identifying a user. This action, just like any other, carries with it a performance implication. The test results in Figure 34-15 demonstrate that CMS sites experience roughly a 10% performance improvement when the CMS authentication module is removed from the web.config file.
Figure 34-15. Authentication module removal
The obvious question is, when can this module be removed safely? Only remove your authentication module if your entire site is available to the CMS guest user. If you have portions of your site that are meant only for specific users, you will need the authentication module in order to identify these users.
If you require authentication for part of your site and still want to take advantage of this performance improvement, you can consider partitioning your site across different CMS servers. This would allow you to remove the module from the cluster that does not require authentication.
Read-Only versus Read/Write CMS Sites
Using the CMS SCA, it is quite easy to change a CMS site from read/write to read-only. As mentioned in Chapter 3, when a CMS server is in read-only mode, roughly 90% of interaction with the database is through stored Structured Query Language (SQL) procedures. An example of this is a read-only CMS server caching CMS pages. When the server is writing such as creating new CMS pages approximately 50% of database queries are ad hoc server queries and the other 50% are stored procedures.
The fact that so much of the processing is happening through stored procedures adds up to roughly a 10% performance increase over read/write sites. Also, a performance increase comes from not having any cache flushes occurring.
CMS Background Processing
CMS background processing is responsible for cleaning up CMS servers. For example, performance of a CMS server is increased by the fact that background processing will remove deleted items from the CMS SQL Server database. These items include CMS pages, channels, and resources. Removing these items during background processing allows better performance during authoring and keeps the database size as small as possible.
Background processing has been significantly improved in CMS 2002. Almost all the work has been moved to the SQL Server. This provides a significant performance gain for the CMS server. However, it does not mean that background processing has no performance impact.
If a browser client requests content that is cached, the CMS server will continue to serve this content as normal. If, on the other hand, the content needs to be retrieved from the CMS database, then there could be a performance hit. The reason for this is that the CMS server might be contending with background processing for the SQL Server resources. Based on this, your CMS server performance will be optimized if you run background processing during your lowest traffic period.