MOSS Design Considerations

MOSS Design Considerations taken from Optimizing Office SharePoint Server for WAN environments& Optimizing custom Web parts for the WAN and my expereinces

Recommendation: Minimize the amount of secured items on a page

Reason: When a user authenticates, two things happen. First, the system validates credentials to determine who the user is. Second, the role provider enumerates the list of SharePoint groups to which the user belongs. Each time a page is requested, the role provider is called again to enumerate all of the groups to which the user belongs.

However, this call for group membership can happen multiple times on a single page. For example, the default Collaboration Portal site template page requires two calls to the role provider when you go to the home page—one for the page itself and one for the image on the page. Each image that is stored in a SharePoint library and is on the page will force an additional call to the role provider to verify permissions, even if all of the images are stored in the same image library. That verification occurs whether the images are added as fields on the page—that is, part of the page's content—or whether they are added to the master page for the site.

Benefit: Reduces the number of security checks and therefore reduces the risk of getting latency.

Recommendation: Minimize the amount and size of images/webparts

Reason: Since the browser only allows you to download 2 items at a time, the more images/webparts, the more time it will take to download the page.

Benefit: Reduces the amount of time it takes to render a page and reduces the amount of data sent over the network

The recommended way is to embed multiple images in a single file and then reference individual images in your page. Not only will file download size decrease, but fewer files result in less network traffic. It is more complicated to author pages by using this technique, but in situations where every round trip and file size counts, it can prove to be valuable way to help improve performance.

Recommendation: Store all images locally on the farm using the relative path versus hardcoded links or the absolute path

Reason: By storing images on a remote location, there is now a dependency on the availability, permissions, and the network to the remote location.

Benefit: The page renders more quickly because you can take advantage of BLOB caching. There is a reduction in network traffic to remote locations and the availability and permissions can all be controlled via the site. Also, when restoring the site in PPE or in another test environment, testing or deployments are not able to affect production as it is self contained.

Recommendation: Reuse existing css files, versus having every group create their own

Reason: By reusing those styles, you can minimize the impact on the page because the page won’t need to download an additional style sheet just to support the different webs. In addition, after the initial site visit the user will already have the core.css file downloaded to their cache. If we do require custom styles, then consider using a custom style sheet that can be used with the blob cache. If you store it in a document library, the style sheet can have a cacheability directive associated with it so that it doesn’t need to be downloaded after the initial page hit. This will have a lower impact on the site than using inline styles, for example, which would be transmitted over the network every time the page is rendered.

Benefit: By using styles that are part of core.css, you ensure that no additional downloads are required for style support. Therefore you are reducing the amount of round trips and amount of data that needs to be downloaded.

Recommendation: Avoid using ViewState in custom web parts, if possible.

Reason: Web Parts may need to track such information as the user, the request, and the data source. In general, there are two common ones you can use with Web Parts: ViewState and server Cache. Using the server Cache class allows you to store state information at the server level. The drawback to using server Cache is that it is not really intended to be used as a per-user state mechanism (although depending on the circumstances it can be made to work that way). Also, the cache information is not replicated throughout all the front-end Web servers on the farm. If your part depends on having that state information present regardless of which front-end Web server a user request ends up hitting, then server Cache is not a good choice. In that scenario, another option is to use Session State. Session State is turned off by default, but is enabled when you activate Microsoft Office InfoPath Forms Services (IPFS) in a farm. When it is enabled, it uses Microsoft SQL Server to track state, which means that session state values can be used no matter which front-end Web server receives the HTTP request. The drawback to session state is that data stays in memory until it is removed or expires. Large datasets stored in session state can therefore degrade server performance if not carefully managed. Because of these constraints, we do not recommend using use session state unless absolutely necessary. You can also experiment with setting ViewState to off for all pages in the site by editing the web.config file for a Web application. It contains a pages element that has an enableViewState attribute. If you have a significant concern about the size of ViewState in the page, you can experiment with setting this attribute to false (it is true by default). If you do this, you need to thoroughly test your site and all of the functionality to ensure that it works properly, because some controls and Web Parts may expect that ViewState will be on.

Benefit: In a low-bandwidth or highly latent environment, avoid ViewState if possible because it adds content to the page both on the download and as any postback. This would apply to other forms of state that also involve transmitting data over the network, such as query strings, hidden fields, and cookies.

Recommendation: For lists, web parts or any other database calls ((i.e. excel services, infopath, product studio, data view web part, etc…), strike a balance between how many trips to the server are required, versus how much data should be retrieved for a request. Minimize the amount of data connections or web parts applied to a page. Also, for controls that emit rows of data, include a property that allows an administrator to control how many rows are displayed.

Reason: Depending on the latency and bandwidth in which the control is going to be used, end users have flexibility to either turn up or down the amount of data that is rendered in each page request. This will impact the number of requests that are required to view all of the data. If the number of rows returned is a property that can be set by end users, consider adding constraints so the choices of one user don’t overwhelm the network.

Benefit: Reduces the page rendering time, reduces network traffic and protects the user from unintentionally configuring their call wrong.