Microsoft Office SharePoint Server 2007 on HP ProLiant servers – performance summary

Introduction......................................................................................................................................... 2 Audience ............................................................................................................................................ 3 Office SharePoint Server 2007.............................................................................................................. 3

Central administration ...................................................................................................................... 3 Topology definition and server roles................................................................................................... 4 New functionality............................................................................................................................. 9 Performance implications ................................................................................................................ 10

Example solution configurations........................................................................................................... 10 Software components ..................................................................................................................... 11 HP servers ..................................................................................................................................... 11 Best practice configurations............................................................................................................. 12

Performance results ............................................................................................................................ 18 Workload scenarios ....................................................................................................................... 18 Results .......................................................................................................................................... 19 IIS application pool tuning and memory usage .................................................................................. 22 Utilizing caching............................................................................................................................ 23 Network design ............................................................................................................................. 24

Sizing solutions ................................................................................................................................. 25 General sizing guidelines ............................................................................................................... 25 Determining required throughput...................................................................................................... 26 Determining the right configuration .................................................................................................. 28 Determining storage ....................................................................................................................... 28

Implementing a proof-of-concept .......................................................................................................... 29 Summary .......................................................................................................................................... 29 For more information.......................................................................................................................... 31

2

Introduction

Microsoft® Office SharePoint Server 2007 provides capabilities to meet business-critical needs like managing content and business processes, simplifying how people find and share information, and enabling enhanced business insight. Additionally, Office SharePoint Server 2007 now supports one integrated platform to address intranets, extranets and Internet applications.

The 2007 Microsoft Office system provides a more comprehensive and integrated set of new exciting capabilities including:

• Collaborative work spaces – Work on projects in context across departments, office and organizations with Office

Groove 2007 – Work effortlessly anywhere on-line or off-line with Office Groove – Access to personal documents via Microsoft Office Outlook 2007 – Create sites quickly using Windows® SharePoint Services application templates – Create a team knowledge base with Shared Notebooks in Microsoft Office OneNote

• Access to information and people – Deploy a new search solution with Office SharePoint Server for Search to incorporate

business data along with information about documents, people and web pages, to produce comprehensive, relevant results.

– Utilize a single platform integrated with Microsoft Office desktops for sharing and publishing information inside and outside the organization

– Simplify organization-wide access to business data in line-of-business systems like SAP and Siebel

• People driven processes – Extend business processes across organizations – Streamline everyday business activities by taking advantage of workflows

Office SharePoint Server 2007 provides significant new and enhanced functionality, compared to SharePoint Portal Server 2003, including improved and enhanced administration. These increased product capabilities should reasonably be expected to require increased server resources, and the HP Solutions Alliances Engineering (SAE) Performance Labs has characterized a typical business scenario (as was used to test SharePoint Portal Server 2003) to determine differences in performance. Deployment of this scenario using Office SharePoint Server 2007 revealed that the new product capabilities, along with new features such as fine-grained security, the security-trimmed UI and new recycle bin, required additional server CPU and memory resources. Upgrading to this new product version will require a review of your current computing environment to ensure you have sufficient CPU and memory resources available.

Office SharePoint Server 2007 enables several new types of caching to help offset increased server resource consumption, but the caching functionality needs to be employed and tuned appropriately to provide optimal benefit to a given workload.

This white paper provides a summary of the performance recorded when characterizing Office SharePoint Server 2007 on a range of HP ProLiant servers and HP BladeSystem

servers running in several typical deployment configurations. It also presents best-practice configuration guidelines, sizing formulae and examples for common collaboration and portal type scenarios. HP intends to publish follow-on white papers which will also cover automated deployment, configuration design and growth, performance and tuning, cache strategies and a broader range of server information and scenarios.

Audience

This paper is intended for people who will be proposing solutions, providing installation services or consulting, and who may be assisting in deploying Microsoft Office SharePoint Server 2007 on HP ProLiant systems and HP BladeSystem servers. It will also be of interest to IT professionals who may be deploying and/or managing Office SharePoint Server 2007 solutions. The paper focuses primarily on guidelines developed during testing performed in the HP Solution Alliances Engineering (SAE) labs regarding deployment and performance on HP ProLiant and HP BladeSystem servers.

HP recommends the information provided herein be used in conjunction with the product solution documentation, and information contained in additional white papers and TechNet articles authored by Microsoft, as noted in the section titled For more information.

Office SharePoint Server 2007

Office SharePoint Server 2007 provides significant improvements, enhancements and new features. These provide increased efficiencies, increased ability to store, manage and present information, enhanced security, and more options to configure solutions and assign roles to servers. Each of these will have some impact on how a solution is configured to meet a business need, and on the solution performance and throughput potential.

Central administration When deploying Office SharePoint Server 2007 in a multi-server scenario, the first server on which the product is installed will, by default, become the host server for Central Administration and its related functions. Other roles can be shared on this server, and this will depend on the throughput requirements and number of servers in the solution. With lower-throughput configurations (typically 1 or 2 servers for a small business, and 5 servers for medium-sized businesses requiring high-availability) the Web Front-end (WFE) servers can be configured to support multiple roles. This is discussed further in the sections Topology definition and server roles and Example solution configurations.

The Central Administration functions, menus and pages have been re-designed and improved. Related functions are now grouped (e.g. Operations, Application management, and so on) making administration easier and quicker. The Shared Services Provider menus (providing such functions as search and backup management) have also been re-designed for ease of use.

There are also key improvements in Central Administration in the areas of creating Web Applications (virtual servers in SharePoint Portal Server 2003) and Site Collections, that were noted especially during lab setup of the solution and creating the required test portal sites. Functions that had to be done manually in SharePoint Portal Server 2003 (e.g. creating IIS application pools and Web Applications correctly on every WFE server) are

3

now handled automatically by Office SharePoint Server 2007 Central Administration. Creating a Web Application and corresponding Site Collection now causes all required structures in IIS (application pools, Inetpub site folder content, and so on) to be created automatically on all WFE servers. This virtually eliminates typographic or consistency errors and results in faster and more efficient sites deployment. In general, it is recommended to install Office SharePoint Server 2007 on all planned WFE servers before creating any virtual applications and site collections. However, if/when the need arises to add a subsequent WFE server, all required application pools and virtual applications relating to existing site collections will be automatically configured on that new server when the SharePoint Products and Technologies Configuration Wizard is run – again improving efficiency and minimizing the chance of configuration errors.

Topology definition and server roles In SharePoint Portal Server 2003 the definition of the solution farm server topology was managed via an X/Y type radio-button matrix to assign servers to roles (WFE, Search, Index, and so on). In Office SharePoint Server 2007 the concept of role-based servers is retained – with servers able to fulfill more than one ‘role’ – but the assignment paradigm has changed.

Additionally, Microsoft has changed the role terminology somewhat to be more broadly applicable given the extensive services that Office SharePoint Server 2007 provides. The Standard edition includes services for Web content, Portal, search, document and records management. The Enterprise edition adds Excel Services; InfoPath Forms Services and line-of-business interoperability services. Figure 1 illustrates the supported services.

4

Figure 1. Products and supported services

Web Front-end servers are defined as those running the Windows SharePoint Services Web Application service, and optionally the Windows SharePoint Services Incoming Email service. Their role is to communicate with the user client desktops (via the user’s browser interface), to solicit data from the database or other servers as needed, and to return the pages of information to the user via appropriate Web Parts that present the results in the desired format.

With Office SharePoint Server 2007, Microsoft has introduced the new role Application Server, reflecting increased capability beyond the traditional SharePoint Portal Server 2003 Search and Index roles. The Query and Index Search services and other new services such as Project Management, Excel calculation, and so on, and related third-party applications now fall under this new Application Server role.

While not strictly a server role per se, there is also a requirement to create at least one Shared Services Provider (SSP). This can provide shared services to users in the farm, or even to a separate farm. Shared Services comprises full-text and property indexing/search, Business Data Catalog, notification/alerts, user profile store, audiences, usage reporting and single sign-on services. There are also cases where more than one SSP may need to be configured (only one Index Search service can be run per SSP) to provide required functionality and range of services. Several of the services (e.g. Query Search) can run on individual servers, or can be spread among WFE servers, this determined by the specific capability and capacity needs for each function or service.

Depending on the business needs and throughput (user population) required, all these roles may be combined on as few as one or two servers, or be distributed appropriately among a larger number of servers to meet high-availability needs and highly specific workloads.

5

There is considerable latitude in how to design and configure an Office SharePoint Server 2007 deployment, and later sections of this paper provide best-practice example configurations of this to meet a range of business, functional, capacity and growth needs.

Figure 2 shows a portion of the Central Administration home page, illustrating the Farm topology and servers.

Figure 2. Central Administration -- Servers in Farm display

Roles are now inferred by the specific service(s) that are selected to run on the server. Selecting a server from the servers in farm display allows viewing the services running on server display. Radio buttons (labeled All, WFE, Search Indexing, Application, Custom, and so on) when selected will highlight the services that need to be running in order to fulfill that server role.

Thus appropriate services (ranging from all on a single-server small and medium business (SMB) deployment, to a single role on a larger multi-server deployment) can be started or stopped as desired on each farm server from the Central Administration pages. Figure 3

6

shows the Central Administration Services on Server display. This is obtained by clicking on a specific server on the Farm topology page shown previously.

Figure 3. Central Administration -- Services on Server display

In this example, the server shown (named BL30PTOP) is the designated single Index Search server. The Custom radio button has been selected, this displaying all possible services that could be started on this server. For this particular server’s role in the Lab test farm, the service of interest is Office Server SharePoint Search which is shown as Started. If this were a simple WFE server, then the Windows SharePoint Services Web Application would need to be running – and that need would be highlighted if the Web Server for medium server farms radio button were selected.

The display shows additional useful information in the Comments field. In this example, it shows that server SPSRDP8 is hosting Central Administration, and that server BL30PBOT is hosting Excel Calculation Services and Windows SharePoint Services Search.

Further control is provided by the Central Administration to designate one or more crawl/index (Search) servers (one per SSP); and to assign search (Query) services across all WFEs or to one or more dedicated search servers, and so on. This is accomplished by selecting the appropriate server, and then clicking on the service, which will open a new screen enabling control and definition of that service.

The management of Indexing/Crawling (hosted in this example on server BL30PTOP) is depicted in Figure 4.

7

Figure 4. Central Administration – Configuring Indexing

The above screen is displayed as a result of selecting server BL30PTOP (as depicted in Figure 3), and then clicking on the Office Server SharePoint Search line.

In general, the screen enables configuring parts of the Query and Indexing/Crawling service. You can specify that the server support indexing and/or serving search queries (see selection boxes at the top of the screen), and to define that crawling either be apportioned across available WFE servers, or (in the example case) that a dedicated server be used. If you do choose to have the Search/Index server use a WFE server locally, make sure that WFE server is removed from the pool of WFE servers available to end-users (i.e. those that are in the Network Load Balancing (NLB) pool). Different input areas will be displayed on the screen based on which selections are made. In the example above, server BL30PTOP is being used to index content and perform content crawling.

The management of Query Search (hosted in this example by server SPSRDP8) is shown in Figure 5.

8

Figure 5. Central Administration – Configuring Search

The above screen is displayed as a result of selecting server SPSRDP8, and then clicking on the Office Server SharePoint Search service line.

This is essentially the same screen as shown in Figure 4, but because the Search Query box (and not the Indexing Content box) was checked, the input parts relate to the Search service. As with the Index example, the service account and password are defined, but in this case the definition of the search index location is also specified. This index may be located on a share (which can be automatically configured for use), or as in this example on a server local drive.

Note that when installing Office SharePoint Server 2007 you have the option to choose a WFE only or a Complete installation. Choosing WFE only limits that server’s role to WFE – you will be unable to assign other roles (e.g. Search) to that server. To maximize the configuration potential in larger deployments you should select Complete. This will only consume marginally more disk space for any un-required components, as only the specific service(s) required for each server’s role need be started and will thus consume CPU/memory/and so on.

New functionality Microsoft has added considerably to the Office SharePoint Server 2007 product functionality by providing many enhanced and new Web parts that provide information to

9

the user. The effect of some of these (e.g., new functionality areas such as Business Intelligence) fall outside the scope of this white paper, as the test workload utilized was functionally similar to that used for prior SharePoint Portal Server 2003 testing. However, some added product features such as security-trimmed UI, fine-grained security and recycle bin were found to have an effect on the server performance and resultant capacity (throughput) achievable. The new Office SharePoint Server 2007 caching schemes can positively affect performance, but need to be tuned to suit the expected workload. Further, the performance difference when employing a read-only workload (simulating users searching, browsing and reading content) compared to a read/write workload (e.g. document management) is more pronounced with Office SharePoint Server 2007 than in previous versions. In that regard, results are shown below for both read and read/write type scenarios, and this distinction is also planned to be included in the forthcoming HP-produced Office SharePoint Server 2007 sizing application.

Performance implications The performance (server throughput) of Office SharePoint Server 2007 will be less than SharePoint Portal Server 2003 when characterized on the same type/class of server. Comparison tests using a general portal workload running on an older HP ProLiant BL20p G3 Intel® Xeon® (2 socket single-core1) WFE server showed a reduction in throughput from about 100 requests/second (SharePoint Portal Server 2003) to about 60 requests/second (Office SharePoint Server 2007). This is to be expected given the added product functionality, especially the additions to security trimming at the site, page, Web part and list item level. Users only see what their site-described role (contributor, approver, reader, viewer, and so on) permits them to see, and an individual user may also have multiple different roles on different sites. These additional security checks are performed every time a user requests a page of information, and result in a decrease in throughput because additional operations are happening on the WFE servers in order to provide pages to the users. This can be confirmed by increased CPU (and memory) utilization.

The same tests run on a range of new HP ProLiant 2-socket dual-core WFE servers (e.g. HP ProLiant DL380 G5) show that this required increase in CPU and memory resources can easily be handled, resulting in per-WFE throughput levels of 100-150 requests/second, depending on the configuration and workload. The correct application of the new Office SharePoint Server 2007 caching schemes will also have a beneficial effect, but must be tuned to suit the workload. Guidelines for typical HP ProLiant and HP BladeSystem throughput are presented in a later section titled Performance results.

Example solution configurations

When configuring the topology of SharePoint Portal Server 2003, solution designers, implementers and administrators were limited to a finite set of prescribed configurations – these being derived in part during joint HP/Microsoft tests in the HP SAE Performance Labs during 2003 prior to SharePoint Portal Server 2003 product release. The purpose was to provide a finite set of tested and characterized server configurations that would provide a range of solution throughput capacities and documented growth paths. Attempting to configure a topology outside those prescribed guidelines resulted in an unsupported 1 Note that throughout this document, any reference to a system having some number of sockets (e.g. 2-socket dual-core) should be construed as all available sockets being populated.

10

topology warning message on the Topology console, implying “this has not been tested and characterized.”

With Office SharePoint Server 2007, Microsoft has removed all such configuration restrictions and warnings and effectively implied “build it how you want.” While this affords a broader range of possible configurations, it may leave architects and administrators – especially those having less familiarity with SharePoint Technologies – wondering where to start when designing a solution to meet specific business needs, and how to plan growth for the future.

This section describes the systems tested, and proposes some best-practice HP ProLiant and HP BladeSystem configurations to meet a range of needs.

Software components The following software components were utilized on the various servers in the HP Labs test farm, each as either X86 (32-bit) or X64 (64-bit) versions as needed:

• Windows Server 2003 SP1 (on all servers) • Microsoft Office SharePoint Server 2007 RTM release (on SharePoint servers) • Microsoft .NET Framework V3.0 (on SharePoint servers) • Microsoft SQL Server 2005 SP1 (on database servers)

The same software components (operating system, .NET V3, Office SharePoint Server 2007) were installed on all servers to be used in testing various configuration topologies. Following installation on the first server, the SharePoint Products and Technologies Configuration Wizard was run, defining that server as hosting Office SharePoint Server 2007 Central Administration, and creating the required farm configuration and related databases. Subsequent servers were also configured via the Wizard to join the same farm. An SSP was also configured, and the Index Search and Query Search services were assigned in various possible configurations to test the results and to determine performance differences. A total of eight (8) Office SharePoint Server 2007 servers were configured for various roles, as described in the following section (HP servers).

The initial database server used for this set of tests was a 4-socket single-core server running the X86 versions of the Windows Server 2003 operating system and of SQL Server 2005 SP1. This provided a comparison point back to earlier SharePoint Portal Server 2003 configuration tests. Testing was also performed with new HP ProLiant 2-socket dual-core database servers running the X64 version of SQL Server 2005 SP1. Tests with SQL Server 2005 SP2 are planned.

HP servers A range of dual-core 2-socket HP ProLiant servers were used for the Office SharePoint Server 2007 servers, being a mix of x86/x64, Intel Xeon/AMD Opteron™, and HP BladeSystem/rack mount types. All the servers tested yielded comparable throughput results and are all excellent price/performance choices as Office SharePoint Server 2007 servers. HP p-Class BladeSystem servers were also included, as many are currently used in SharePoint Portal Server 2003 deployments and companies may wish to retain these when migrating to Office SharePoint Server 2007. HP c-Class BladeSystem servers are also being

11

evaluated and are expected to provide similar performance (as demonstrated in other HP tests), but will provide improved cost/performance due to their more efficient power and cooling. The section titled Performance results provides more details on the servers tested (items 1 through 9 listed below).

The following summarizes the tested servers and roles: (QC = quad-core, DC = dual-core, SC = single-core)

1. HP ProLiant BL20p G4 3.00 GHz DC Intel 5160, 4GB memory – X86 WFE/Admin 2. HP ProLiant BL20p G4 3.00 GHz DC Intel 5160, 4GB memory – X64 WFE 3. HP ProLiant BL25p G1 2.6 GHz DC AMD™ 285 (Rev E), 4GB memory – X86 WFE 4. HP ProLiant BL25p G1 2.6 GHz DC AMD 285 (Rev E), 4GB memory – X64 WFE 5. HP ProLiant DL380 G5 2.66 GHz DC Intel 5150, 8GB memory – X64 WFE/Index 6. HP ProLiant DL385 G2 2.60 GHz DC AMD 2218 (Rev F), 8GB memory – X64 WFE/Query 7. HP ProLiant BL20p G3 3.60 GHz SC Intel Xeon, 2GB memory – X86 WFE (comparison point) 8. HP ProLiant DL580 G2 2.0 GHz SC Intel Xeon, 4GB memory – X86 SQL Server (comparison

point) 9. HP ProLiant DL380 G5 2.66 GHz DC Intel 5150, 8GB memory – X64 SQL Server

The following servers are currently being tested and results will be reported in a planned follow-on paper:

10. HP ProLiant DL385 G2 2.60 GHz DC AMD 2218 (Rev F), 8GB memory – X64 SQL Server 11. HP ProLiant BL460c (c-Class blade) 3.00 GHz DC Intel 5160, 4GB memory – X64 WFE 12. HP ProLiant BL460c (c-Class blade) 2.66 GHz QC Intel X5355, 4GB memory – X64 WFE

Best practice configurations While Office SharePoint Server 2007 retains the concept of role-based servers, as it was introduced with SharePoint Portal Server 2003, it now includes several enhancements and additions. The recommended Office SharePoint Server 2007 configurations and growth paths are therefore very similar to those for SharePoint Portal Server 2003 and will be familiar to current SharePoint administrators. The changes in topology definition in Office SharePoint Server 2007 allows more latitude in designing configurations; however you should not stray too far from the recommendations shown below without performing a proof-of-concept test in your own environment.

Because Office SharePoint Server 2007 can be deployed and configured in so many ways, there is no single simple way to estimate the number of users that can be supported by a given configuration without making some base assumptions. There are several factors that affect throughput – number of users, user authentication methods, frequency and complexity of user operations, caching, customization of Web parts and pages, and so on. The performance results shown later in this paper are based on a set of reasonable assumptions with respect to how the farm configurations were set up, site design, content and tuning (e.g., caching), and user access methods and authentication. As such, they should be broadly applicable to a majority of typical deployment scenarios.

The best-practice configurations shown below are designed to provide specific capabilities that will meet the requirements for a range of business needs.

12

Entry Level configurations These configurations are designed to support a lower number of active users (and thus throughput needs) as might be found in the SMB or low-mid market. A further assumption is that high-availability (normally provided by multiple load-balanced WFEs and Clustered SQL Servers) is not required. This means a simple and cost-effective solution can be provided by deploying the software (either Windows SharePoint Services V3 for team collaboration, or the full Office SharePoint Server 2007 solution set) on either one or two servers. Figure 6 illustrates these configurations.

Figure 6. Example entry-level configurations

The expected size of the corpus of information can likely be supported by server internal storage bays, or by adding a direct-attached storage enclosure connected to the server’s Smart Array controller, to satisfy required storage space needs. A low user population usually implies lower throughput and thus lower storage I/O needs, which can be handled by such a configuration. The two-server solution is recommended if it is anticipated that the solution may need to be extended beyond a single server in the future. It is much easier to grow the solution if the Office SharePoint Server 2007 and SQL Server components are already on separate servers. A further WFE server need only be added (to create a WFE NLB pool) to provide increased performance, and as a by-product provide redundancy to the WFE component.

13

Suitable HP ProLiant servers for such entry-level configurations would be the DL380 G5, DL385 G2, (and DL580 G4, or DL585 if a scaled-up solution is desired), as illustrated in the examples above. Sufficient storage can likely be configured using the server internal drives (up to 8); else adding a storage enclosure is an option. If a customer does not already employ HP BladeSystem servers, then these may not be a suitable choice for a new entry-level configuration, as the cost to deploy these will be higher than a rack solution until three or more servers are required. However, if the customer plans on adding servers to an existing BladeSystem infrastructure, or plans on deploying a number of new application solutions, then blade servers would certainly be appropriate. The c-Class HP ProLiant BL460c, with up to two Quad-Core or Dual-Core Intel Xeon processors, would be most applicable.

Highly Available configurations These solutions are usually applicable to mid-market and enterprise scenarios, where high availability is deemed mandatory. A configuration is considered highly available if the failure of a single component does not prevent users accessing the solution, albeit at potentially reduced performance levels. This means eliminating single points of failure for both the WFE and database components by creating a server “farm.” This is accomplished by using a minimum of two (2) WFE servers (each supporting both WFE and Query Search roles) in an NLB pool, using a single application server for the Index Search role; and using a minimum of two (2) SQL Servers in an active/passive cluster connected to common shared storage (typically provided by a SAN). Note that failure of a single Index Search server will prevent recent (updated) crawls of content from being available, but does not prevent users searching against current query data. The choice of configuration will therefore be influenced by your particular business needs as regards timeliness and relevance of such information. Figure 7 illustrates the highly available reference configuration.

14

Figure 7. Example highly-available configuration

The five-server configuration is the baseline solution to provide high-availability. Such solutions can be sized such that the WFE servers combined can provide more capacity than is normally needed, thus should one server fail the remaining server(s) can still provide an acceptable level of performance as may be dictated by service level objectives (SLOs). The single active SQL Server will also be under-utilized when supporting only two WFEs (typically capable of supporting between four and six WFEs, depending upon the user workload). The configuration can also be expanded, if capacity needs dictate, by adding further WFE servers configured with the same roles and adding them to the WFE NLB pool.

An alternative to using an active/passive SQL cluster might be to use separate database servers and storage and employ database mirroring, as provided by SQL Server 2005. It is outside the scope of this paper to make recommendations as to whether database mirroring might be more appropriate to your specific needs; and you are strongly encouraged to refer to the related Microsoft documentation discussing database mirroring noted in the section For more information at the end of this paper.

Suitable HP ProLiant servers for highly-available configurations would be the DL380 G5, DL385 G2, (and DL580 G4, or DL585 if a 4-socket solution was desired), as illustrated in the example above. Deployment onto an HP BladeSystem solution would also be cost-effective, as the minimum number of servers required is higher than the deployment “Rack vs. Blade break even point” of 3 servers. The HP ProLiant BL460c dual-core 2-socket c-Class BladeSystem server would be the most appropriate to use for WFE and application servers. This model would also be appropriate as a database server, being able to support between four and six WFEs depending on the workload. An alternative would be the HP ProLiant

15

BL480c 2-socket quad-core server (these are full-height servers, each requiring 2 enclosure slots). Figure 7 shows the SQL Server cluster utilizing SAN storage provided by an HP StorageWorks 1500 Modular Smart Array (MSA1500) SAN array. The requirement for high-availability does not always dictate a large user population, or a need for large storage. However, HP can offer a range of suitable SAN storage arrays (MSA, Enterprise Virtual Array (EVA), and so on) to suit all needs.

Application optimized configurations These configurations are suitable for high-mid-market and enterprise solutions where high performance and continuity of business is a requirement. They are expansions of the highly-available configurations above, where application roles (Query Search, Index Search, project management, and other applications) have been deployed on dedicated servers. This configuration will provide the required capacity for those functions and also “unload” the Query Search role from the WFE servers thus providing increased WFE capacity and retaining redundancy. Figure 8 shows an example c-Class BladeSystem deployment.

Figure 8. Example Application Optimized configuration

16

These configurations also employ two or more WFE servers in an NLB pool to provide redundancy and required capacity – the number of servers predicated on the workload to be supported. A later section titled Sizing solutions provides guidelines for calculating this, and the planned Office SharePoint Server 2007 HP Sizing application will allow exploring configuration options and “what if” scenarios. Similarly, a database technology providing server redundancy is used (active/passive cluster, “N+1” cluster, or database mirroring); with a further option to use database log shipping to an additional (possibly remote) SQL Server to help provide continuity of business or disaster recovery. An N+1 cluster implies N active nodes and one passive node. This would be used if the total WFE and application server load exceeded that supportable by one active SQL server (typically between 4 and 6 WFEs per 1 active SQL server, depending upon the workload).

Figure 8 above depicts an HP c-Class BladeSystem deployment. The enclosure contains a number of BL460c 2-socket dual-core servers used as WFEs and application servers, and two BL480c 2-socket quad-core servers as an active/passive SQL Server cluster. There is also room for further expansion, or to deploy additional solution applications if required. Given the likelihood of increased storage needs in this case, the example shows SAN storage provided by an HP StorageWorks 6000 Enterprise Virtual Array (EVA6000) 2C4D SAN array, providing fully-redundant dual-path and dual controller fibre connectivity. A wide range of HP StorageWorks EVA and XP SAN solutions are available to meet the stringent needs of enterprise deployments.

Recommended servers are the same as for the highly-available configurations. The following HP ProLiant servers and HP BladeSystem servers are applicable, depending on the customer deployment preference:

• Rack mounted – DL380/DL385 2-socket dual-core for WFE, application server or database server

(supports 4-6 WFEs) – DL580/DL585 4-socket dual-core for resource-intense application server (e.g.

SSP/Search/Index, as this is more easily scaled-up than scaled-out), or for database server (estimated to support 6-10 WFEs)

• p-Class BladeSystem (if deploying/migrating to existing p-Class blade servers) – BL20p/BL25p 2-socket dual-core for WFE, application server or database server

(supports 4-6 WFEs) – BL40p/BL45p 4-socket for resource-intense application server (e.g. Business

Intelligence (BI)), or for database server (estimated to support 6-10 WFEs)

• c-Class BladeSystem (best price/performance solution, lower power and cooling costs) – BL460c 2-socket dual-core for WFE, application server or database server (supports 4-

6 WFEs) – BL480c 2-socket quad-core for resource-intense application server (e.g. project

management or BI), or for database server (estimated to support 6-10 WFEs)

Office SharePoint Server 2007 is a highly modular and scalable solution that is ideally suited to BladeSystem deployments. For highly-available mid-market and enterprise class deployments, the HP c-Class BladeSystem solution provides the best price/performance, lowest cooling and power costs, and the most flexibility in deploying suitable servers; and thus optimizing performance as workload and capacity needs change over time.

17

Performance results

The purpose of the performance study summarized in this paper was to gain understanding of how best to configure and size Office SharePoint Server 2007 solutions, and to provide some comparison to SharePoint Portal Server 2003 for benefit of customers migrating to the new product version. To that end, HP Labs elected to use a workload for this test series that was comparable to that used for previous SharePoint Portal Server 2003 studies. Further studies (already in progress) will use an extended workload that characterizes some of the new features of Office SharePoint Server 2007 (e.g. extranet publishing, workflow, project management, BI, usage analysis, and so on). These will be reported on in planned follow-on white papers, and results and sizing for these functions are planned to be incorporated into the HP Office SharePoint Server 2007 Sizing application over time.

Workload scenarios The workload employed for this test series comprised two main segments. The first is a read-only type workload that represents users who are consumers of information (reader or viewer role), rather than contributors. The second is a more read/write workload that includes some percentage of content modification, reflecting that portions of the user population are contributors of content. Both workloads use a range of frequently utilized portal functions, that are each weighted according to an expected percentage likelihood that a user would employ that function during a typical portal access period. The implementation of the workloads, using a high-end performance toolset that emulates user browser activity, also enables exploring the effects of changing the percentage ratios to observe the effect of stressing specific functions. Note that the percentages shown below do not sum to 100, but are rather the percentage likelihood of a given function occurring during each pass through the test scripts. These scripts ran continuously in a loop during the test period. Tests were executed against a small number of random top-level sites and a modest number of team sites. Future tests will explore larger site collections and size of content to determine the impact, although this is likely to be predicated on the efficient design and deployment of related databases and content, rather than server capacity.

Read-only workload This workload comprised typical “information viewing” activities – browsing document libraries, opening documents, viewing lists of information, home page access, and so on. Emulated users were all from an Office SharePoint Server 2007 user group designated as “readers” and were connected to the portal as domain-authenticated users via NTLM. Both the Object cache and BLOB cache were active and set to default cache expiration and size values. The following are the main activities and percentages:

• Home page – 80% • Browse announcements list, opening a random announcement – 75% • Browse Events calendar list, opening a random event – 75% • Browse a Document Library – 75%

– Open a random document within the library – 10%

• Execute a Search using a random query string – 25% – Open a random document from the search results – 10%

18

Read/write workload This workload is similar to the above, but was executed against more sites and content and included some data modification activity in the form of document check-out, modification and check-in as this read/write activity is likely the most common. A range of percentages was also tested for the check-out/in functions to determine the degree of effect. Emulated users were all from an Office SharePoint Server 2007 user group designated as “contributors” and were connected to the portal as domain-authenticated users via NTLM. Both the Object cache and BLOB cache were active and set to default cache expiration and size values, but non-checked-in documents were not cached. The following are the main activities and percentages:

• Home page – 70% • Browse announcements list, opening a random announcement – 65% • Browse Events calendar list, opening a random event – 65% • Browse a Document Library – 65%

– Open a random document within the library – 10% • Execute a Search using a random query string – 25%

– Open a random document from the search results – 10% • Browse a specific document library on a random site – 10%...40%

– Check-out/modify/check-in a random document

Results Tables 1 and 2, below, summarize example results for a range of tested servers and workload variations. The columns list the WFE server, and averages for throughput in requests/sec for a single WFE server, WFE CPU%, SQL Server CPU%, Client network traffic in KB/sec. A “request” implies a user performing a portal site operation that will result in a new page of information being returned, and is broadly equivalent to the Windows Monitor “ASP.NET Requests per second” metric, and is the key throughput performance metric. A user request (e.g. Query, List open, page selection, and so on) will usually result in the WFE obtaining required data from the SQL Server for each page web part, performing fine-grained security UI trimming on the data, rendering the page and sending it to the user’s browser. Caches operating at various levels may preclude the need to get the relevant data and/or various “blob” graphics data that the page may require from the database if these are currently cached, thus reducing database access and end-to-end time and improving throughput.

Table 1. Read-only workload

WFE Server Throughput WFE CPU% SQL CPU% Net KB/sec

BL20p G3 SC X86 60 85 10 6700

BL20p G4 DC X86 148 85 32 10000

BL20p G4 DC X64 140 85 32 10000

BL25p G1 DC X86 132 85 28 8900

19

WFE Server Throughput WFE CPU% SQL CPU% Net KB/sec

BL25p G1 DC X64 124 85 24 7900

DL385 G2 DC X64 * 138 85 30 9800

DL385 G2 DC X64 **

100 75 14 7000

DL385 G2 DC X64 ***

85 65 12 6000

Table 2. Read/write workload

WFE Server Throughput WFE CPU% SQL CPU% Net KB/sec

BL20p G4 DC X86 126 85 34 9000

BL20p G4 DC X64 120 85 34 9000

BL25p G1 DC X86 112 85 31 8200

BL25p G1 DC X64 105 85 30 7700

DL385 G2 DC X64 118 85 33 8700

NOTES:

• BL20p G3 = 3.60GHz SC Intel Xeon • BL20p G4 = 3.00GHz DC Intel 5160 • BL25p G1= 2.6GHz DC AMD 285 Rev E • DL385 G2 = 2.60GHz AMD 2218 Rev F • * = DL385 G2 DC X64 WFE + DL580 G2 2.0 GHz SC Intel Xeon SQL Server • ** = DL385 G2 DC X64 WFE + DL380 G5 2.66 GHz DC Intel 5150 SQL Server • *** = DL385 G2 DC X64 WFE + DL380 G5 2.66 GHz DC Intel 5150 SQL Server

The following are general observations from the results:

• The Dual-Core Intel 5160 3.00GHz servers performed slightly better than the Dual-Core AMD 285 servers; however the newer Dual-Core AMD 2218 servers showed essentially equivalent performance of their Intel counterpart. Choice of Intel or AMD based servers is therefore not predicated on pure performance, but rather a customer choice or price/performance criteria.

• Tests were run with both DL580 G2 2.0 GHz SC Xeon (X86 32-bit) and DL380 G5 2.66GHz DC Intel 5150 (X64 64-bit) SQL Servers. As shown for the read-only workload above (see data marked * and **) the 2-socket dual-core SQL Server consumed approximately half the CPU as the single-core server, and can thus provide about twice the

20

capacity. The CPU data also confirms that such a 2-socket dual-core SQL Server could support up to 6 WFE servers (read-only workload). This tested configuration also reflects a best-practice 2-server SMB configuration (2-socket dual-core X64 WFE and SQL Servers).

• A similar test to the above was also performed at reduced load such that the combined WFE and SQL Server CPU was at about 80% (see data marked *** above), this being similar to a single (WFE and SQL combined) server running at about 80-85% CPU. This result would be similar to an X64 single-server SMB configuration using a 2-socket dual-core server.

• The X64 (64-bit) tests showed slightly less WFE performance than the X86 (32-bit) tests as measured “under a microscope in a lab environment.” Despite the apparent small difference in performance shown with this set of tests, HP recommends deploying X64 to capitalize on the increased memory potential and to future-proof server investments. WFE, application and SQL servers can all benefit from the increased memory potential. All tuning is a trade-off of one resource against another. Tuning methods such as employing caching will require additional memory (as enabled by X64) and can lower CPU consumption, both resulting in increased potential throughput and efficiency. The X64 2-socket dual-core database server tests (data marked ** and *** above) showed that an HP ProLiant 2-socket dual-core X64 platform is ideally suited as a SQL Server 2005 database server.

• Though not shown in detail in the results above, performance of Windows SharePoint Services V3 Team sites is slightly higher than Office SharePoint Server portal sites, as has previously been seen with SharePoint Portal Server 2003, and more notably so with workloads having a high proportion of read vs. read/write activity.

• Workloads having a higher proportion of read/write activity will generally result in lower per-server throughput, especially in cases where sufficient WFE and application servers are causing high database server activity (frequent data modification).

• Detailed tests on the Index/Crawl and Query Search functions are ongoing; however initial observations show that these functions are very efficient in Office SharePoint Server 2007. Once the required Web Parts were loaded (the first access with cold caches), query search results were returned very rapidly, with the search Web Part typically reporting processing the request in about 0.03 seconds.

Rules-of-thumb:

• For Office SharePoint Server 2007 sites, assume a per-WFE server throughput maximum of 100-120 requests/second, depending on the degree of read/write activity in the expected workload. If unsure, use 100 requests/second as a guideline.

• If the Query Search service will be running on the WFE servers, use 85 requests/second. • For the 2-server SMB configuration (all Office SharePoint Server services running on a

single server), assume a maximum throughput of 75-100 requests/second. For a single-server SMB configuration (All Office SharePoint Server services and SQL Server running on one server), assume a maximum throughput of 50-75 requests/second.

• For Windows SharePoint Services team sites, assume a per WFE server throughput of 100-150 requests/second. If unsure, use 120 requests/second as a guideline.

• Assume a single active X64 2-socket dual-core SQL Server can support between 4 and 6 WFE/application 2-socket dual-core servers of the same type/power, depending on expected workload.

21

• Although not yet explicitly tested, HP estimates, based on other testing, that a 4-socket dual-core server (e.g. HP ProLiant DL580/585) would provide 1.8 times the capacity of a 2-socket dual-core server.

• If the business needs require frequent crawl/indexing of content, or a large corpus of information exists, plan on deploying a dedicated server for this task. The Index Search server number and speed of processors will influence the crawl speed and how many crawl threads can be run (e.g. a dual-core 4-socket server can run 8 threads). Sufficient memory is also important as documents are loaded into buffers for processing on the crawl server, thus the greater the memory capacity the more documents that can be processed in parallel. Given the restriction of one Index Search service per SSP, this is more easily scaled-up (more cores), rather than scaled-out (more servers).

• Microsoft has proposed a common set of definition examples for users in the Office SharePoint Server 2007 documentation, describing frequency of use and a requests/second (RPS) to supported users ratio for each. These user definitions are summarized as: – Light user, access every 180 secs (20/hr), 1 RPS = 180 active users – Typical user, access every 100 secs (36/hr), 1 RPS = 100 active users – Heavy user, access every 60 secs (60/hr), 1 RPS = 60 active users – Extreme user, access every 30 secs (120/hr), 1 RPS = 30 active users

• From the above, a single server entry-level deployment should be expected to support up to about 50-75 requests/second depending on workload. From the suggested user definitions, this single server solution could therefore support SMB deployments where a smaller (but more active) user population could be expected.

• The majority of mid-market and small enterprise deployments can be supported by a five-server highly-available solution. Two WFE/Query Search servers should be expected to support between 175-250 requests/second, depending upon the extent of read/write and search activity in the workload. Using a mix of typical and heavy user access indicates that 10,000+ users could be supported.

• Enterprise solutions, even using a centralized rather than distributed deployment, can be supported due to the modular design of Office SharePoint Server 2007, as the appropriate number of WFE and application servers can be configured. Use an Application Optimized configuration for this scenario, which can potentially support hundreds of thousands of users.

IIS application pool tuning and memory usage Testing revealed that Office SharePoint Server 2007 WFE servers will typically use more memory than was seen for SharePoint Portal Server 2003. WFE servers for SharePoint Portal Server 2003 were typically X86 single-core 2-socket, with 2GB memory. For Office SharePoint Server 2007, HP recommends X64 2-socket dual-core servers with at least 4GB memory. More than 4GB may be required depending upon tuning parameters and strategies that leverage memory against CPU utilization – some HP testing was able to exhaust 4GB memory on X64-based WFE servers with various memory consumptive tuning schemes. As memory is a relatively less expensive component than CPUs this trade-off can be beneficial, and the solution designer should consider configuring increased memory where the situation would warrant it, such as when using server-side caches.

22

HP noted during testing that when creating a Web Application (and associated site collection) that the default is that a unique IIS application pool be used for each. This can have several benefits – should some unexpected error in a site cause a problem it will be localized to that site collection, additionally the worker process will be caching content related to those specific sites. Worker process sizes of between 250-300MB were observed on X86 WFE servers, and between 400-500MB on X64 WFE servers. Note that there are also other application pools and related IIS processes to support Central Administration, SSP, and so on, on the various WFE servers. The best-practice approach will be to consider which Web Applications should share an application pool, and which should be unique. Using multiple application pools can be beneficial, but it is easy to over-do by always taking the default settings (use new pool). Each related process has to load an instance of the .NET runtime in memory, so un-needed (excessive) application pools can waste memory.

The various test results and rules-of-thumb above were derived from testing with multiple application pools (one per Web Application) and with 1 worker process per pool.

Utilizing caching Caching, using WFE memory and/or WFE disk-local caches will improve end-to-end performance (and thus response times) by reducing accesses to the database server. Even a fairly short (say, 5 minute) cache expiry time can provide noticeable performance improvements. Microsoft has incorporated three distinct cache schemes in Office SharePoint Server 2007, each relating to specific goals. Utilizing and tuning these to suit a given workload will maximize performance. It is beyond the scope of this paper to discuss these in detail, and related references are provided in the section titled For more information. However, the following provides an overview and recommendations based on HP testing to date.

Object cache Office SharePoint Server 2007 supports caching of certain page items, such as navigation data and data accessed through cross-list queries. Caching page items is fast, and reduces the requirement to continually access field data from the database each time a page is rendered. Caching for objects in a page can almost always be used, however when users have a document checked-out, caching is bypassed. The Object cache also improves the speed of Search queries, as prior cross-list query results can be cached. Line-item security checks are still performed on the results set however, as a given user may not have the rights to view certain content in a cached results set derived from another user’s query.

The Object cache is enabled by default, with a pre-set cache memory value. The size and other cache parameters can be changed on a per-site basis via the Site Settings menu. HP testing was performed with the Object cache enabled at its default size.

BLOB cache This is a disk-based cache scheme that can be enabled on a per-site basis, and should be set consistently on each WFE server. In a typical site there are likely several references to image files (BMP, JPG, and so on) or to CSS style sheets or JS script files. These can be cached to avoid repeated database access for what are essentially static objects, and thus improve page response times. The cache is disabled by default, and is enabled by editing a line in the site WEB.CONFIG file found in the IIS Inetpub folder structure related to the site

23

on the server’s system disk. Edit the file and search for the second instance of “BLOB” to get to the right line, which looks like:

<BlobCache location=”c:\blobCache” path=”\.(gif|jpg|png|css|js)$” maxSize=”10” max-age=”86400” enabled=”false” > The maxSize parameter is the maximum size of the disk cache in GB, max-age is the cache expiration time in seconds (86400 = 24 hours). Enable the cache by changing the enabled parameter to “true” and save the file. Create the required folder in C:\blobCache. Then issue an IISRESET in a command window. HP testing was performed with the Blob cache enabled at the default size and expiration age.

Output cache The output cache is designed for sites that are published out to external readers (e.g. extranet) using the publishing features incorporated into Office SharePoint Server 2007 (previously performed using Content Management Server with SharePoint Portal Server 2003). It utilizes memory on each appropriate WFE to cache pages and their content. HP has not yet characterized publishing sites and thus can not offer first-hand results or recommendations in this paper. Follow-on work is planned in that regard, however you are encouraged to get further information from a number of technical articles published on Microsoft TechNet, refer to the section titled For more information. Control and definition of the cache is via the Site Settings menu, whereby the Publishing feature must first be enabled at both the site collection and site levels. This exposes a set of additional menu commands (Site Collection Administration/Site collection output cache, and Site Administration/Site output cache) which allow setting the Output cache parameters at the site collection and site levels.

Network design As seen with SharePoint Portal Server 2003, there is the potential for fairly high network traffic between clients and WFEs, and between WFEs and the database and application servers with Office SharePoint Server 2007. The cache schemes discussed above can reduce the database traffic somewhat, however for larger deployments (e.g. mid-market and above) HP recommends designing a suitable network infrastructure that employs two virtual LANs. This is intended to separate the Client-WFE HTTP traffic from the WFE-database traffic and thus improve network efficiency. A Gigabit LAN (if available) is a less complicated option that can be used, but a solution designer will need to determine if adding the estimated SharePoint solution network traffic to an existing network is feasible. Observations during testing at about 100 requests/second throughput rate showed the following average network traffic characteristics:

• Traffic to clients – 9000KB/sec • WFE traffic (R/W) – 11,000KB/sec receive, 20,000KB/sec send • WFE traffic (R/O) – 5,000KB/sec receive, 20,000KB/sec send • SQL traffic (R/W) – 4,000KB/sec receive, 10,000KB/sec send • SQL traffic (R/O) – 2,000KB/sec receive, 10,000KB/sec send

HP and Microsoft developed a design for an appropriate dual VLAN during test of SharePoint Portal Server 2003, and detailed this in the Solution Accelerator for Intranets

24

document set published on Microsoft’s website. This design is also suitable for larger Office SharePoint Server 2007 deployments, and a pointer to this material is given in the section titled For more information.

Sizing solutions

You may already be familiar with the HP Sizing application for SharePoint Portal Server 2003, available on HP ActiveAnswers. HP is in process of developing a similar sizing application for Office SharePoint Server 2007. This sizing application embodies all the relevant rules-of-thumb, best-practice configuration designs and appropriate calculations based on user needs input. This makes sizing applications and designing storage subsystems, and exploring “what-if” scenarios easier.

If you wish to try your own ballpark “back of an envelope” solution designs and estimations, HP offers the following guidelines.

General sizing guidelines In earlier sections, HP has presented recommendations for the types of HP ProLiant and HP BladeSystem servers that are appropriate for various configurations and roles as part of an Office SharePoint Server 2007 solution. The rules-of-thumb contained in the Performance section give guidelines as to the performance and capacity levels you should expect for a range of workload types.

In order to perform a first-approximation sizing estimate you will need to know a number of key attributes and values pertaining to your expected business needs – specifically the number of users, the concurrency of use, and the nature/intensity of the workload. Each is important as follows:

• Number of users – this can have an impact on the amount of storage needed depending upon the business and the users’ activity. Consider these cases: – A local government solution to handle electronic document retention and management.

Potentially low user population, but high document needs per user with multiple versions stored.

– A mid-market solution with many team sites and higher user population, however team collateral is transient (short-term projects and storage needs), so potential storage may be lower despite a higher user population.

– A University solution to support hundreds of thousands of potential users, each being provided with a storage quota (e.g. 1GB per student).

• Number of users combined with degree of concurrency – this will have a direct impact on the throughput needs of the solution servers. The degree of concurrency defines how many active (or concurrent) users may be using the solution at a point in time.

• The nature/intensity of the workload – some users may be casual information browsers, some concerned with content maintenance and modification, and other (typically smaller) groups may be employing resource-heavier applications. The workload, generalized as the number of light/typical/heavy/and so on, users will have a direct impact on both sizing and on the ideal configuration.

25

Determining required throughput To determine general needs based on user types you can use the generic user types proposed by Microsoft, noted in the earlier rules-of-thumb. Use those estimates to determine the approximate total number of requests/second required and then determine the number of servers needed to support that load. Alternatively, you can use the following more detailed methodology to calculate the required throughput.

The following list provides key sizing metrics, along with typical values as a guideline:

• Number of users – the number of potential users (or subscribers) with access to the portal • User concurrency – the percentage of all users who may access the portal during the day.

This is typically between 10% and 50%. This is an important number and one that is usually a point of contention.

• Operations (requests) per user per day – accesses to the portal home page, searches, category browses, document retrievals, media viewing and so on. Depending upon the user’s role (reader, author, reviewer, or contributor), this will usually range between the values suggested by Microsoft for the various user types.

• Hours per day – hours in the business day. (Portal site access may cross time zones; therefore, 10 hours per day might be a typical number for a company spanning the United States.)

• Peak factor – a ratio of how much the peak usage exceeds the average usage. Size the systems for peak usage so that performance does not degrade during busy periods.

Note: Peak factor is an approximate number that estimates the ratio of the peak portal-site throughput to its average throughput. This number typically ranges from 1 to 4.

Using the following formula and the quantitative metrics of each portal’s usage characteristics, you can estimate the required portal peak throughput, in requests per second (RPS).

Number of users

× Percent of active users per day

× Number of requests per active user per day

× Peak factor

360,000 × Number of hours per day

The constant 360,000 is derived from the following equation:

100 (percent conversion) × 60 (minutes per hour) × 60 (seconds per minute)

• You should also break down the requests per active user per day by the type of portal or site, and related functions such as:

o Corporate portal access o Divisional portal access o Team Site usage o My Site usage

26

The following example illustrates how to estimate required throughput for a divisional portal component of the total solution workload. This process enables sizing the number and type of servers to support the various portal components and services that the total solution will require.

Table 3 shows example characteristics representing a Divisional Portal site supporting approximately 10,000 typical users (about 36 tasks/hr per 10 hour day) at a concurrency of 40%. This is a reasonably diverse workforce group, utilizing a mix of common portal functions and a small percentage of complex functions. Most users typically access the site using simple activities such as locating information by browsing categories, or searching for documents that match their needs, or reading divisional news or announcements on the home page.

Note the weight applied to document management (including document check-in and document upload). These more complex activities take several steps to accomplish; therefore, they are rated as 3 times as intense as other functions.

Table 3. Divisional Portal - example characteristics

Characteristic Value

a. Number of potential users 10,000

b. Concurrency % 40

Number of common requests per active user per day 300 × (weight = 1.0) =300

Number of complex requests per active user per day + 10 × (weight = 3.0) = 30

c. Total number of requests per active user per day 330

d. Number of hours per day 10

e. Peak factor 2

10000 × 40 × 330 × 2

360000 × 10 = 73.33 RPS

As shown, these characteristics yield a predicted peak throughput requirement of about 74 requests per second (RPS) for this workload component. You should perform this same estimation exercise for each projected key portal and site type. The sum of these per-portal estimates represents the required total solution throughput in requests per second.

Note also that all users may not be accessing the portal sites and being authenticated in the same way. If you are planning on a published extranet site, users will likely access that anonymously (anonymous access is an option when creating a site). Office SharePoint Server 2007 documentation indicates that anonymous access to a published site means that the related server(s) can provide a much higher throughput rate (possibly double). Using Output caching, as noted earlier, is reported to as much as double that throughput again, depending on cache settings. In short, consider all potential users and their mode of access.

27

Once you have an estimate for required servers, apply that to the best practice configurations noted earlier.

Determining the right configuration The optimum configuration will be dictated by a number of parameters – some relating to throughput needs, some to business imperatives (e.g. high availability), and some to likely needs for growth over time. The decision may be simple. If your needs fit within an entry-level type configuration, then use a one-server (everything), two-server (separate Office SharePoint Server and SQL Server) or even three server (2 WFE + 1 SQL) configuration if throughput needs dictate, and high-availability is not an issue. Whereas, if high availability is required, map your server needs onto the highly-available configuration and determine the number of WFE servers needed. If you have special requirements to run potentially resource-consumptive applications, then deploy those on dedicated servers.

Determining storage Office SharePoint Server 2007 requirements for storage are broadly similar to those for SharePoint Portal Server 2003 for each of the key Office SharePoint Server 2007 server roles (WFE, Search, Index, and Database). The following are general guidelines for determining storage needs, and are also utilized to calculate and design storage in the Office SharePoint Server 2007 HP Sizing application, currently in development.

Web Front-end (WFE) servers • Allow approximately 6GB for the operating system, .NET Framework V3 and Office

SharePoint Server 2007 installation files • Swap file is set to the same as physical memory by default (e.g. 4GB) • Allow space for storing IIS logs, if you plan on retaining these for analysis of web server

activity

Index and Search Application servers • Allow approximately 6GB for the operating system, .NET Framework V3 and Office

SharePoint Server 2007 installation files • Swap file is set to the same as physical memory by default (e.g. 4GB) • Determine the total size of the corpus of information that you plan to store across all

content databases. Allow for 30% of that value as the maximum estimated size of the content index. You do not need to allow for double the size to handle Index merges (as was the case with SharePoint Portal Server 2003), as Office SharePoint Server 2007 performs incremental merges.

• Refer to the Microsoft Search Capacity Planning paper, referenced in the section For more information, as Microsoft may revise the current 30% guideline in the future following further evaluation.

Database servers • Allow approximately 5GB for the operating system, .NET Framework and SQL Server

installation files • Swap file is set to the same as physical memory by default (e.g. 4GB) • Allow 1.5GB for the farm configuration database

28

• Estimate the content database(s) size by estimating your expected initial corpus of information size and multiplying by 1.20, noting that if versioning is enabled that a copy of each version is stored. You may wish to apply limits to the number of versions stored, if this is appropriate for your business and/or retention policies.

• Disk space for database log files will vary based on total number of databases and log settings. Guidelines for SQL Server 2005 may be found in the Microsoft document Physical Database Storage Design referenced in the section titled For more information at the end of this paper.

• To ensure available space for database growth, plan for twice the quantity of data you initially expect – that is, use a 50% fill factor. As Office SharePoint Server 2007 provides a dual-level recycle bin, documents that are “deleted” may be in the level 1 or level 2 bin for some period of time and have not been truly deleted, depending on the recycle bin policies in use.

In addition to the above, size the total needs for each server to allow at least 25% free space, employ appropriate storage management practices to defragment storage volumes and apply SQL Server database management best practices regarding backups, log management, and so on.

Implementing a proof-of-concept

As a matter of best practice for all deployments, HP recommends implementing a proof-of-concept using a test environment that matches as closely as possible the planned production environment. In this way, appropriate performance and scalability characterizations can be obtained. For help with a proof-of-concept, contact an HP Services representative. For more information, speak with an HP salesperson or reseller, or contact HP directly using the contact information available at http://www.hp.com/hps/contacts/index.html.

Summary

The following are the key findings and recommendations:

• Office SharePoint Server 2007 provides significantly increased functionality, a broader range of application support and increased security; however these features come at an increased cost in terms of server resource consumption (compared to SharePoint Portal Server 2003).

• Office SharePoint Server 2007 requires increased memory to perform optimally; however using tuning techniques that leverage memory (caches, for example) is a good price/performance tuning trade-off.

• Office SharePoint Server 2007 retains, and extends, the role-based server paradigm introduced in SharePoint Portal Server 2003, to support configuration of highly scalable solutions.

• HP ProLiant dual-core servers (rack-mount and BladeSystem) provide the CPU power and memory capacity to support the resource needs, and the range of servers available are an ideal match for the modular multi-server design of Office SharePoint Server 2007.

29

• Powerful solutions can be configured on as few as 1 or 2 servers, and can scale-out to a highly-available deployment supporting specialized applications and preserving continuity of business for the mid-market and enterprise customers.

• The process to size a solution configuration is very similar to the process used for SharePoint Portal Server 2003. HP is developing an Office SharePoint Server 2007 sizing application (similar to that available for SharePoint Portal Server 2003) that will propose best-practice server and storage configurations based on user/workload data input.

• Use the sizing guidelines and configuration recommendations presented in this white paper, in conjunction with related materials produced by Microsoft which are cited in the section For more information. Microsoft has produced a wealth of technical product documentation, much of it available on Microsoft TechNet. These materials should be considered mandatory reading for solution designers and administrators.

• The HP SAE Performance Labs plan on additional Office SharePoint Server 2007 characterization, exploring the new features in more detail and testing SharePoint Technologies based business solutions running on HP server and storage technologies. Further performance white papers are planned over time.

30

For more information

HP ActiveAnswers SharePoint resources http://h71019.www7.hp.com/ActiveAnswers/cache/70675-0-0-0-121.html

HP ProLiant servers http://www.hp.com/go/proliant

HP BladeSystem c-Class servers http://h18004.www1.hp.com/products/blades/components/c-class-components.html

HP Storage technologies http://www.hp.com/go/storage

Office SharePoint Server 2007 TechNet landing page

http://technet2.microsoft.com/Office/en-us/library/eb2493e8-e498-462a-ab5d-1b779529dc471033.mspx

Physical Database Storage Design http://technet2.microsoft.com/Office/en-us/library/a1f9acca-9280-47bb-85fa-52b9a7be7a861033.mspx

SQL Server database mirroring for Office SharePoint Server 2007

http://technet2.microsoft.com/Office/f/?en-us/library/60c88afa-6d59-469d-9092-842813316bd01033.mspx

Office SharePoint Server 2007 Search Capacity Planning

http://technet2.microsoft.com/Office/en-us/library/5465aa2b-aec3-4b87-bce0-8601ff20615e1033.mspx?mfr=true.

Office SharePoint Server 2007 cache operations

http://technet2.microsoft.com/Office/en-us/library/9f3cfe3f-01b5-406e-8615-04735ae422861033.mspx?mfr=true

Microsoft Solution Accelerator for Intranets (network design)

http://www.microsoft.com/downloads/details.aspx?FamilyID=7cdc1f2d-f550-49e0-9b74-318da11ba1b4&DisplayLang=en

© 2007 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation. Intel, Itanium and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. AMD and AMD Opteron are trademarks of Advanced Micro Devices, Inc.

4AA1-1793ENW Rev. 1, April 2007