Microsoft SharePoint Portal Server (SPS) has a reputation for being slow. This reputation is in some small way deserved, but it's largely a reflection of developers' failure to use the extensive caching mechanisms in SPS to maintain performance. In this Daily Feature, I’ll explain the caching options in SPS and how to use them to improve performance.
What makes SPS so slow?
Even a single Web part can make SPS feel slow. Most developers use the embedded script method to create Web parts. The embedded script has the code for the Web part within the Web part itself. SPS can only draw the dashboard site after the last bit of embedded code for all of the Web parts has executed. Because of this, even one misbehaving Web part can make the entire dashboard site appear slow.
One of the keys to developing SPS Web parts is the value of caching results. Although SPS performs well on most inquiries, some inquiries can tax its resources. In order to maintain performance, the number of resource-intensive inquiries must be limited to those that are providing value. In a Web environment, it’s normal to see the same request over and over again as the same user navigates back across the same pages.
Managing how SPS uses and controls caching is essential to maintaining performance. No matter how efficient your Web parts are, sooner or later they'll need to be cached to conserve resources when the solution scales up to a larger number of users.
SPS caching falls into two major categories: server caching and client caching. Server caching is great for information that is the same for all users, and it can significantly improve server scalability. Client caching is useful when the information is personalized to the user. It can improve server scalability even more than server caching. Let’s look at both of them in detail.
Most of the focus on caching in SPS implementations is on server caching. This is for two reasons. First, Microsoft recommends server caching in SPS. Second, server caching is very flexible. There are many ways to implement it. SPS allows a Web part to cache part of its information or the entire Web part itself. It’s even possible for an administrator to cache the entire dashboard site.
Most of the Microsoft-supplied Web parts use a mechanism that saves the entire contents of the Web part to an application variable. The next time the Web part runs, it checks to see if there is still data in the application variable. If the data is available, SPS uses it rather than doing the regular processing. This forces the use of caching. The administrator doesn’t have to tweak or change anything.
Microsoft also advocates Web part caching. This mechanism, which is set through the SPS administrative interface, causes SPS to save the output of the Web part automatically and discard it after a period of time that you select. This is a step above variable caching because the data can expire after a period of time. It’s also better because it allows the administrator to change the frequency with which the information is updated.
The process for turning on Web part caching is simple. First, open the dashboard site with the Web part that you want to change caching for and expand the Administrative Links button (if necessary). Click the content administrative link to call up a list of Web parts, and then the Web part you want to modify. Next, scroll down and click the Show Advanced Settings link. Scroll down to the bottom of the page and change the setting for Should The Content Of This Web Part Be Cached. Finally, click the Save button. The settings will take place immediately. From then on, the Web part will run once, and then the cache will be used on each subsequent request until expiration.
Starting with SPS Service Pack 1, Microsoft gave SPS the ability to cache an entire dashboard site. This can improve performance because SPS saves the whole dashboard site instead of individual Web parts. There are, however, a few limitations to dashboard site caching. First, some dashboard sites can’t be cached. Specifically, you can’t turn on caching for the following built-in dashboard sites:
- Document Library
- Standalone Dashboard sites
If you enable dashboard site caching on these standard sites, they'll no longer function correctly.
The other limitation to dashboard site caching is that it uses the sum of all of the Web part caching settings. As a result, you must set all of the Web parts to be cached for all users. The smallest cache time for any of the Web parts is the time that is used for dashboard site caching. These rules apply to all Web parts, except for the search Web part. Microsoft hard-codes this part into the system.
Turning on dashboard site caching is more difficult than turning on caching for Web parts. Unlike the other caching features, you can’t set it with the Administrative Interface For SPS. To turn it on, you must run the Portalperf.vbs file included with Service Pack 1. The syntax of the command is cscript portalperf.vbs http://NetBIOSName/workspace/dashboard site dashboard sitedef enable.
Similarly, you'd turn off dashboard site caching by using cscript portalperf.vbs http://NetBIOSName/workspace/dashboard site dashboard sitedef disable.
For instance, if you wanted to enable caching for the root dashboard site for a workspace named Knowledge on the server named Greece, the command would be cscript portalperf.vbs http://Greece/Knowledge/Portal dashboard sitedef enable.
Unlike server caching, client caching offers only one real option. You turn on client caching for some Web parts within your dashboard site by telling the browser to cache the information returned for a period of time. To do so, you must use an external Web development language, such as Microsoft’s Active Server Pages (ASP). In your development language, you control caching just like you would if you were developing your own Web site.
In ASP, for instance, you'd use the following lines of code to specify caching:
Response.CacheControl = “Public”
Response.Expires = 60 ‘ Cache for the next 60 minutes
In SPS, you'll set up your new Web part as an external link. External content requires that you set up only the URL from which to get the external link. SPS implements this as an IFRAME tag. The IFRAME tag is an inline frame. It used to be that you had to define frame sets prior to starting the page. With the addition of the IFRAME tag, you can now open a frame to other content on the fly.
The key to using client caching is to understand how the browser caches information. Browsers treat each URL as unique, and they cache information based on that URL. The effect is that each set of content to display must have a unique URL.
The good news is that the browser will take into account query string parameters. Those are the parameters after the question mark (?). For instance, in the request http://localhost/aspcode/news.asp?Type=Industry, the query string includes a variable, Type, that is set to Industry. From the browser's perspective, that request would be different from http://localhost/aspcode/news.asp?Type=Corporate.
One of the advantages to client caching is that users themselves can clear the cache and get new information. By selecting Refresh in their browser, users can force the browser to re-request a page and all of its frames. With server caching, all of the application variables must be cleared. Only an administrator can do this.
The disadvantage of client caching is that it tends to make the page look like popcorn as it comes up. The page itself comes up with all of the frames for the content that has been specified as external content. However, the content in those frames doesn’t load when the page first displays. The content of the frames is requested immediately after the page itself appears. Because the responses for the frames come back at different times, the frames appear to pop up like popcorn. As a side benefit of this kind of population, you make more requests to the server and thereby automatically create more threads of execution. This will improve the ability for your application to scale across multiple processors.
Taking client caching to the next level would naturally suggest caching the entire dashboard site on the client. However, this is specifically not supported because of the way the dashboard site framework functions. The result of this is that you can’t get around the popcorn appearance when you’re using client caching. You also can’t prevent at least one request from going to the server when the user navigates to a dashboard site. You can, however, use server-side dashboard site caching with a page that utilizes a series of Web parts that are client cached to reduce the workload on the server.
Cache, check, and charge up SPS performance
Caching is an essential part of performance management with SharePoint Portal Server. Every SPS site needs to carefully consider the ways in which caching can be used to improve performance—and to maintain performance under an increasing number of user requests. Server caching is more flexible, but ultimately it can limit the amount of personalization you can do, and it may not be as efficient as client caching.