MOSS 2007 Architecture and Performance Considerations

1) Introduction

A very common problem that many clients encounter with their MOSS implementation is can their production environment handle the amount users? This can be a complex question to answer which can be driven by many things (many times understanding the usage of the site). Knowing this is a broad question this article will try to answer this at a high level and provide direction on areas where deeper investigation on a case by case basis. Hopefully decisions makers can walk away after reading this with a good understanding of what considerations there are with a MOSS implementation.

2) Knowing Your MOSS Implementation
First many need to make that decision on whether to use MOSS or vanilla WSS 3.0. Here are two articles that spell out the difference of the features clearly:

• Which SharePoint technology is right for you?
• Microsoft Office SharePoint Server 2007 feature comparison

There are several things that are going to drive performance when setting up your MOSS environment. Typically when breaking this down and tuning out all the noise it really comes down to understanding how MOSS will be used. There are a couple different types of sites that may be implemented within a MOSS deployment:

• Publishing Site (Intranet) – This could be characterized as content that would be read a lot by internal employees. It would have a medium level of transactions most of which would be reads with some insert, update and delete transactions associated with the management of the content. Typically this content is fairly static as the most dynamic content on any Intranet site is news, calendars, etc.
• Team Collaboration – This can be a highly transactional environment where document libraries, lists, forums, discussion boards, task/issue lists, calendars, workflows, etc. are being updated on a daily, hourly or down to the minute. Knowing both how many users and their planned usage of this environment will greatly dictate the performance of this type of site.
• My Sites – This again is similar to a Team Collaboration environment except that that each user of the SharePoint environment will have their own site to do the same things which they may or may not be used heavily. The amount of transactions per user may not be that high (unless there is strong adoption) however what can be compelling is the amount of users making transactions.
• Extranets – Can be similar to Team Collaboration environments except that they are externally accessible to partners so that they can collaborate on the same information. SharePoint can be configured to allow multiple authentication protocols to access the Team Collaboration content that is sitting behind a firewall.
• Public Internet Site – This is a public site that is available to the entire world using anonymous access. This site would require the ability to support a high level of read transactions and make sure that the SharePoint environment is secure.

This is not inclusive but a list of the most common ones. Please also note that characterizations of low, medium and high in the above explanation is discussing the level of transactions relative to each other.

It is important to note that question still does not change in regards to building up any application. We always need to know, how many users will there be, what the users are doing, what events may cause a high volume of usage, etc.

3) Physical Architecture
First let us get an understanding of what the physical architecture of a standard MOSS environment may look like. Keeping this simple there are three types of servers that will be part of your topology:

• Web Front End Server(s) (WFEs): What users will directly access.
• Application Server(s): Search Index, Excel Services, Form Services, etc.
• InfoPath Form Services Note: A little misconception is that Form Services actually run on the WFEs because it uses ASP.net and IIS to serve up the content. If there will be heaving web enabled InfoPath usage it must be evaluated (InfoPath Forms Services Best Practices and InfoPath Forms Services Architecture).
• Excel Services Note: It is better known that Excel Services does heavily use the WFEs and it is the only service that supports load balancing on the WFEs (Excel Services Architecture).
• Search Notes: There are two roles with Search, the Query Role and Index Role. To simplify the discussion the Index Role's job is to build indexes of content which are given to the Query Role. The Query Role is accessed by the user when they perform a search. The Query Role is typically installed on the WFE while the Index Role will run on the Application Server. This decouples the two from one another to support redundancy if the search index needs to be rebuilt, more server power needs to be allocated to building the index, etc.
• Database Server(s): This is the Configuration Database for the MOSS Server farm and the all of the Content Database(s). There could be performance ramifications for how the Content Database(s) are partitioned logically with respects the content stored within it but it would have to be something really really really large. However the size of the Content Database itself should not be an issue, please review (Demystify MOSS Content Database Sizing). It boils down to how agile you are with the administration of your databases (backing up and restoring them).

This article, Plan for availability (Office SharePoint Server), spells out the most common physical architectures to be considered. The most common one often recommend is the five server farm depicted below from the Plan for availability (Office SharePoint Server) article.

More WFEs can always be added and loaded balanced to help support the amount of users using the MOSS Farm. More application servers can be added to provide dedicated resource for service however something like the search index service cannot be scaled out across applications servers. Probably the most effective configuration is the six server configuration where there are two applications servers. One application server is dedicated to search while the other will support less intensive services.

3.1) Licensing
To be honest a five server farm is not always required, it really comes down to what sort of service level agreement (SLA) has been set up which will dictate the level of redundancy that needs to be supported. It is not uncommon for a four server farm configuration where there is one WFE, one Application Server and a DB cluster because the client already has this infrastructure in place. Any decision maker should challenge themselves with the following question. If you are already willing to make an investment to create a highly-available data tier, why not do the same for the web tier? Depending on the licensing agreement with Microsoft or Software Vendors the cost of the server software itself is nominal when it comes to the cost of CALs for MOSS. The following article has a short write up on the various licensing agreements out there for MOSS (Logical architecture model: Corporate Deployment).

3.2) Reality Check
It is important to give a quick reality check on some of the services and components that many want to use with MOSS.

3.2.1) Excel Services
This is quick overview of excel services however it Excel Services is not a robust tool. After reading the list of Unsupported Features in Excel Services you will find out it may not provide what is needed for Excel power users (macros are not supported). It would not be recommended to use Excel Services as a replacement for enterprise reporting platform while tools such as Performance Point Server are built for this. Understand its limitations before using it.

3.2.2) InfoPath Services
Before going off and making a huge investment in InfoPath Form Services and web enabled Forms, please review the following two articles:

• InfoPath 2007 features that are unavailable in InfoPath Forms Services
• Web browser compatibility in InfoPath Forms Services

Web enabled InfoPath forms are fantastic tools for building forms to quickly capture information. However the golden rule with them is if you have complex user interfaces requiring multiple views, lots custom .Net code, etc. you may have eclipsed InfoPath and better off using traditional ASP.net forms.

3.2.3) Workflow
Business users can use SharePoint Designer and developers can use Visual Studio to author workflows that can be hosted within SharePoint. However the SharePoint Designer does have lots of limitations and Visual Studio can be cumbersome and you will have to build up a bunch of things. A workflow engine like K2 BlackPearl should be used. The following article lays out workflow options and considerations for the various tools.

3.3) Extranet Topology
It is worth discussing what an extranet topology may look like as many clients have requirements to support access to the MOSS environment to the outside. With SharePoint 2003, setting up external access was not a trivial, natural thing although this is not the case with MOSS 2007. Regardless if the access is external using Active Directory (AD) credentials over SSL, Forms Based Authentication (FBA) with SQL Server, ADUM, etc. all that is being set up is a new Zone which will have a specific authentication protocol associated to it. Users can all have access to the same content and the SharePoint Security is used for authorization (security trimming) content within MOSS.

Design extranet farm topology (Office SharePoint Server) is an article written by Microsoft that lays out the details of the various different configurations for an extranet. There various different perimeter and publishing models. The following diagram from Design extranet farm topology (Office SharePoint Server) is a very common configuration.

In this model, placing the application servers on the corporate network can be beneficial as efficiencies can be gained with building the search index as server doing the index is closer to the data sources it is querying. Plan Security Hardening for Extranet Environments provides detailed insight into the configuration of all the ports between the DMZ and the Corporate Network.

3.5) Topology Performance Testing Results
In an effort to provide some easy performance numbers, Microsoft completed some tests of the various different topologies. If an environment requires the ability to support more users, it can always be scaled by adding more WFEs or further segregating the application server services to their own dedicated machine. Here are some high level statistics summarized in Plan for performance and capacity (Office SharePoint Server). Please note, that the hardware configuration may not be identical and there are many factors that could affect these statistics.

• Pure Anonymous Access on Internet (read only) (Estimate performance and capacity requirements for Internet environments (Office SharePoint Server)):
• 2 (WFE) x1 (App) x 1 (DB) – 2,927 reads per second
• 4 (WFE) x1 (App) x 1 (DB) – 5,612 reads per second
• NTLM Access on Internet (read only) (Estimate performance and capacity requirements for Internet environments (Office SharePoint Server)):
• 2 (WFE) x1 (App) x 1 (DB) – 632 reads per second
• 4 (WFE) x1 (App) x 1 (DB) – 1,304 reads per second
• NTLM Access with full Collaboration (Estimate performance and capacity requirements for portal collaboration environments):
• 2 (WFE) x1 (App) x 1 (DB) – 141(read-only) reads per second, 79 operations per second
• 4 (WFE) x1 (App) x 1 (DB) – 248 (read-only) reads per second, 128 operations per second

It is interesting to note that the study by Microsoft found that after four web servers had been added for a single database server there were diminishing returns. Research on a case-by-case basis would need to be completed to gain a full understanding of how many users will be using the server concurrently and in what capacity.

4) Logical Architecture
Finally the logical architecture is probably one of the more complex things that topics that needs to be discussed. The following article Logical architecture model: Corporate Deployment is the most comprehensive in regards to this. It has detailed information on how an enterprise logical deployment should be configured. The following diagram was developed from that article and is from in the following blog posting (Investing in Logical Architecture Design Samples).


Some important things to walk away with are:

• MySites are partitioned from team sites into their own Site Collection. This is extremely important, highly recommended and should be done from the beginning as it difficult to move them later (Design My Sites Architecture).
• Internet and Intranet\Team Sites are as well partitioned into their own Site Collections as collaborative environments tend to consume more resources than publishing sites. The logical architecture even goes as far a partitioning Intranet and the Team Sites from each other. Site Collections can have their own dedicated Content Databases and can they can easily moved to their dedicated WFEs if there are future performance problems. Even if entire implementation were to be physically installed on one box but logically separated like this the solution will have much more ability to scale.
• Dedicated application servers (Shared Services Providers) should be set up to support the various different types of sites. For example the external web site would use a different SSP than the intranet for security reasons.
• Various Application Pools are recommended to achieve higher redundancy between, security, performance, etc. Zones are then used to logically control the authentication protocol.

5) Tools for Understanding the Topology
The next part of the this article will go into a discussion of the various different tools that can be used to help determine what the architecture should be (System Center Capacity Planner 2007) and how it should be monitored after it has gone into production (MOSS 2007 Management Pack for MOM 2005).