Microsoft Office SharePoint Server 2007 on HP ProLiant
servers – performance summary
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
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
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
– 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
• 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.
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.
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
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
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.
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
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.
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
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
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.
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. 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
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.
Microsoft has added considerably to the Office SharePoint Server 2007 product
functionality by providing many enhanced and new Web parts that provide information to
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.
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-core 1 ) 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
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.
topology warning message on the Topology console, implying “this has not been tested and
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
This section describes the systems tested, and proposes some best-practice HP ProLiant and
HP BladeSystem configurations to meet a range of needs.
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.
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
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
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
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.
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.
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
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.
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
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
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
• 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-
– 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.
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.
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.
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%
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
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
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
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
DL385 G2 DC X64 85 65 12
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
• 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
• 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
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-
• 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
• 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.
• 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
• 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
– 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.
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.
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
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.
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
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.
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
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
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.
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
– 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.
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
• 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
Number Percent of active Number of requests per Peak
× × ×
of users users per day active user per day 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
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
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
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
a. Number of potential users 10,000
b. Concurrency % 40
Number of common requests per active user per day 300 × (weight = 1.0)
Number of complex requests per active user per day + 10 × (weight = 3.0) =
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
= 73.33 RPS
360000 × 10
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.
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.
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
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
• Allow approximately 5GB for the operating system, .NET Framework and SQL Server
• Swap file is set to the same as physical memory by default (e.g. 4GB)
• Allow 1.5GB for the farm configuration database
• 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.
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
• 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
• 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.
• 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.