Estimate performance and capacity requirements for InfoPath Forms Services environments (Office SharePoint Server)
Applies To: Office SharePoint Server 2007
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2016-11-14
In this article:
Key characteristics
Test environment
Test results
Recommendations
This performance and capacity planning scenario incorporates a single Microsoft Office SharePoint Server 2007 farm that is running InfoPath Forms Services. The farm is used to publish InfoPath form templates. Note that the test results that are shown in this article are specific to InfoPath Forms Services in Office SharePoint Server 2007. Test results may not be representative of the performance characteristics of Microsoft Office Forms Server 2007.
Key characteristics
Key characteristics describe environmental factors, usage characteristics, and other considerations that are likely to be found in deployments based on this scenario.
The key characteristics for this scenario include the following:
**Authentication, access control, and authorization **Integrated Windows authentication is used in this scenario. Typically, sites and content are secured either by using security groups or by granting access to individual users based on their user accounts. Authentication and authorization affect throughput and require a network connection between farm servers and domain controllers. Throughput is the number of operations that a server farm can perform per second. Throughput is measured in requests per second (RPS).
Associated directory service This scenario incorporates an associated Active Directory directory service to provide user and organizational information. This information is used by Office SharePoint Server 2007 features to provide advanced functionality such as presence, targeting, and audiences.
Complex (read/write) user operations In a forms environment, users view and contribute to content. Throughput targets for this scenario are designed to ensure reasonable response times for complex user operations such as uploading form templates or filling out forms.
Data and site growth over time In addition to estimating the initial data volume, an Office SharePoint Server 2007 collaboration environment must also allow for data and site growth over time. A server farm that is designed for the initial data volume can quickly become insufficient.
User response times Target user response times for common, uncommon, long-running, and rare operation are listed in the User response time table at the end of the article Plan for software boundaries (Office SharePoint Server). Some organizations might tolerate slower user response times or might require faster user response times. The expected user response time is a key factor that determines overall throughput targets. When you have more users, you require a higher throughput target to achieve the same user response time.
User concurrency A concurrency rate of 10 percent is assumed, with 1 percent of concurrent users making requests at a given moment. For example, for 10,000 users, 1,000 users are using the solution simultaneously, and 100 users are making requests.
Test environment
Testing for this scenario was designed to help develop estimates of how different farm configurations respond to changes to the following variables:
Complexity of the form
Type of user operation
Different data connections
The number of document libraries to which forms were submitted
It is important to note that the specific capacity and performance figures presented in this article will be different from the figures in real-world environments. The figures presented are intended to provide a starting point for the design of an appropriately scaled environment. After you have completed your initial system design, test the configuration to determine whether your system will support the factors in your environment.
For information about how to test your deployment, see Tools for performance and capacity planning (Office SharePoint Server)and the InfoPath Forms Services 2007 Web Testing Toolkit (https://go.microsoft.com/fwlink/?LinkId=129547).
Assumptions
- 64-bit architecture Only 64-bit Web servers were used in the test environment. Although Office SharePoint Server 2007 can be deployed on 32-bit servers, we recommend that you use 64-bit servers in farm deployments. For more information, see the 64-bit vs. 32-bit section in the article About performance and capacity planning (Office SharePoint Server).
Test definitions
This section defines the test scenarios and provides an overview of the test process that was used for each scenario. Detailed information such as test results and specific parameters are given in each of the test results sections later in this article.
Test definitions
| Solution name | Test description |
|---|---|
Baseline solution |
|
Open form |
|
Save to a single SharePoint document library |
|
Submit form via a SharePoint data connection |
|
Baseline solution with business logic and complex controls |
|
Save form via a SharePoint data connection (five document libraries) |
|
Submit form via a SharePoint data connection (five document libraries) |
|
Lab Topology
To provide a high level of test-result detail, several farm configurations were used for testing. Farm configurations ranged from one to eight Web servers and a single database server computer that is running Microsoft SQL Server 2005 database software. Testing was performed with four client computers. All Web server computers and the database server were 64-bit, and the client computers were 32-bit.
The following table lists the specific hardware that was used for testing.
| Computer role | Hardware |
|---|---|
Web server |
2 quad-core Intel Xeon E5345 2.33 gigahertz (GHz) processors 8 gigabytes (GB) of RAM |
Database server |
4 quad-core Intel Xeon 3.2 GHz processors 16 GB of RAM Five 146-GB 15,000-RPM hard disks, RAID 5 |
Client computer |
2 Intel 3.06-GHz processors 2 GB of RAM |
A gigabit (1 billion bits/sec) network was used in the test environment. We recommend that you use a gigabit network between servers in an Office SharePoint Server farm to ensure sufficient network bandwidth.
Software
The following table describes the software that was installed on the servers that were used for this testing.
| Computer role | Software |
|---|---|
Web server |
The Windows Server 2008 Enterprise Edition operating system with Service Pack 1 (SP1), with the most recent updates. Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1), x64 version. Note that testing was performed before the release of the Infrastructure Update for Microsoft Office Servers. The Microsoft .NET Framework version 3.5. |
Database server |
Windows Server 2008 Enterprise Edition with SP 1, with the most recent updates. SQL Server 2005 database software. The .NET Framework version 3.5. |
Client computer |
Windows Server 2003 Enterprise Edition with SP 1, with the most recent updates. |
Test results
The following tables show the test results for InfoPath Forms Services on Office SharePoint Server 2007 with SP1. For each group of tests, only certain specific variables are changed to show the progressive impact on farm performance.
Note that all the tests reported on in this article were conducted without think time, a natural delay between consecutive operations. In a real-world environment, each operation is followed by a delay as the user performs the next step in the task. By contrast, in this testing, each operation was immediately followed by the next operation, which resulted in a continual load on the farm. This load introduced database contention and other factors that can adversely affect performance.
For information about bottlenecks in InfoPath Forms Services, see the Common bottlenecks and their causes section later in this article.
How business logic and complex controls in a form affect throughput
The two tests in the following table show how the addition of business logic and complex controls to a form affects farm throughput. Differences between the tested form templates are shown in the table at the end of this section.
| Web servers | Performance of baseline solution (RPS) | Performance of baseline solution with business logic and complex controls (RPS) |
|---|---|---|
1 |
325 |
292 |
2 |
633 |
547 |
4 |
1076 |
954 |
6 |
1052 |
1095 |
8 |
1102 |
1065 |
The following graph shows that the addition of business logic and complex controls does not necessarily affect farm throughput in a linear manner. Throughput significantly improves for both test solutions at four Web servers. The trend lines are similar for both test solutions. In summary, when business logic and complex controls are used in a form, the demand on Web servers in the farm is increased and may indicate that you should add Web servers to the farm.
.gif "Graph of impact of business logic")
The following table shows the variables in form template design for the complex form solution.
Form template variables
| Parameter | Baseline solution | Baseline solution with business logic and complex controls |
|---|---|---|
Bottleneck |
Database disk I/O |
Database disk I/O |
Data connections |
1 (submit to Web service) |
1 (submit to Web service) |
Main data source |
Flat (all elements direct children of myFields) |
Hierarchical (elements grouped into sections) |
Close-on-submit rule |
Yes |
Yes |
Sections |
0 |
6 (2 optional) |
Repeating tables |
0 |
1 |
Data validation |
4 |
10 |
Rules |
0 |
3 |
Postbacks |
2 |
1 |
First request optimization |
Yes |
No |
How different operations affect throughput
These tests show how different operations that are performed against a specific solution affect farm throughput.
The following table shows the difference in throughput when different operations (submit to Web service, open form, save to a single document library, submit to a SharePoint data connection) are performed against the same form.
All postbacks are 10 KB.
How different operations affect throughput
| Web servers | Baseline solution (submit to Web service) (RPS) | Open form (RPS) | Save to a single document library (RPS) | Submit to a SharePoint data connection (RPS) |
|---|---|---|---|---|
1 |
325 |
302 |
331 |
241 |
2 |
633 |
591 |
416 |
313 |
4 |
1076 |
847 |
429 |
301 |
6 |
1052 |
877 |
426 |
292 |
8 |
1102 |
825 |
431 |
305 |
As shown in the following graph, the save to a single document library and submit to a SharePoint data connection operations had a significant impact on throughput. Throughput was not improved by adding Web servers to the farm. However, the performance of the submit to Web service and open form operations improved when Web servers were added.
In this test scenario, optimum performance was achieved by using four Web servers. Better results are possible by using a more powerful database server. Additionally, it is a good practice to put the content databases on a different database server from the session state database. This practice improved farm performance by at least 10 percent in our test lab.
.gif "InfoPath Form Server operations impact chart")
The following table shows the form template design parameters that were used in this test scenario.
Form template variables
| Parameter | Baseline solution | Open form | Save to a single document library | Submit to a SharePoint data connection |
|---|---|---|---|---|
Bottleneck |
Database disk I/O |
Not applicable |
Database locks |
Database locks |
Data connections |
1 (submit to Web service) |
1 (submit to SharePoint document library) |
1 (submit to Web service) |
1 (submit to SharePoint data connection) |
Main data source |
Flat (all elements direct child of myFields) |
Flat |
Flat |
Flat |
Close-on-submit rule |
Yes |
Yes |
No |
Yes |
Sections |
0 |
0 |
0 |
0 |
Repeating tables |
0 |
0 |
0 |
0 |
Data validation |
4 |
4 |
4 |
4 |
Rules |
0 |
0 |
0 |
0 |
Postbacks |
2 |
1 |
2 |
1 |
First request optimization |
Yes |
No |
Yes |
No |
The effect on throughput of single vs. multiple document libraries
The tests in the following table show the effect on throughput of submitting a form to a single document library versus distributing the form submissions to multiple document libraries.
The effect on throughput of single vs. multiple document libraries
| Web servers | Baseline (RPS) | Submit to a single document library via a SharePoint data connection (RPS) | Submit to five document libraries via a SharePoint data connection (RPS) | Save to a single document library (RPS) | Save to five document libraries (RPS) |
|---|---|---|---|---|---|
1 |
325 |
241 |
229 |
331 |
319 |
2 |
633 |
313 |
436 |
416 |
523 |
4 |
1076 |
301 |
485 |
429 |
637 |
6 |
1052 |
292 |
455 |
426 |
591 |
8 |
1102 |
305 |
468 |
431 |
621 |
As shown in the following graph, distributing forms among multiple document libraries can have a good effect on performance. In small deployments, the use of multiple document libraries is not as important a factor to consider. However, as the number of forms saved to a single library grows past the limits discussed in Plan for software boundaries (Office SharePoint Server), performance can be greatly enhanced by using distributed document libraries, which reduces contention. For large-scale enterprise deployments, we recommend that you design forms that submit data through a data connection instead of forms that are saved to document libraries.
.gif "InfoPath Forms Server impact of data connections")
The following table shows the form template design parameters that were used in this test.
Form template variables
| Parameter | Submit form via a SharePoint data connection | Submit form via a SharePoint data connection (five document libraries) | Save to a single document library (RPS) | Save to five document libraries (RPS) |
|---|---|---|---|---|
Bottlenecks |
Database locks |
Database locks |
Database locks |
Database locks |
Data connections |
1 (submit to SharePoint document library) |
1 (submit to Web service) |
1 (submit to SharePoint document library) |
1 (submit to Web service) |
Main data source |
Flat (all elements direct child of myFields) |
Flat |
Flat |
Flat |
Close-on-submit rule |
Yes |
Yes |
Yes |
Yes |
Sections |
0 |
0 |
0 |
0 |
Repeating tables |
0 |
0 |
0 |
0 |
Data validation |
4 |
4 |
4 |
4 |
Rules |
0 |
0 |
0 |
0 |
Postbacks |
1 |
1 |
1 |
1 |
First request optimization |
No |
No |
No |
No |
Recommendations
This section provides general performance and capacity recommendations. Use these recommendations to determine the capacity and performance characteristics of the starting topology that you created in Plan for availability (Office SharePoint Server) and to decide whether you have to scale out or scale up the starting topology.
Hardware recommendations
For specific information about minimum and recommended system requirements, see Determine hardware and software requirements (Office SharePoint Server).
Note
Memory requirements for Web servers and database servers depend on the size of the farm, the number of concurrent users, and the complexity of features and pages in the farm. The memory recommendations in the following table may be sufficient for a small or light usage farm. However, memory usage should be carefully monitored to determine whether more memory must be added.
Scaled-up and scaled-out topologies
You can estimate the performance of your starting-point topology by comparing your topology to the starting-point topologies that are provided in Plan for availability (Office SharePoint Server). Doing so can help you quickly determine whether you must scale up or scale out your starting-point topology to meet your performance and capacity goals.
If you have determined that your deployment does not require high availability, read Plan for redundancy (Office SharePoint Server) for information about how to determine your requirements for redundancy.
To increase the capacity and performance of one of the starting-point topologies, you can do one of two things. You can either scale up by implementing server computers that have more capacity or scale out by adding additional servers to the topology. This section describes the general performance characteristics of several scaled-out topologies. The sample topologies represent the following common ways to scale out a topology for an InfoPath Forms Services scenario:
To provide for more user load, add Web server computers.
To provide for more data load, add capacity to the database server role by increasing the capacity of a single (clustered or mirrored) server, by upgrading to a 64-bit server, or by adding clustered or mirrored servers.
Maintain a ratio of no more than eight Web server computers to one (clustered or mirrored) database server computer. Although testing in our lab yielded a specific optimum ratio of Web servers to database servers for each test scenario, deployment of more robust hardware, especially for the database server, may yield better results in your environment.
Estimating throughput targets
Many factors can affect throughput. These factors include the number of users; the type, complexity, and frequency of user operations; the number of postbacks in an operation; and the performance of data connections. Each of these factors can have a major impact on farm throughput. You should carefully consider each of these factors when you plan your deployment.
Office SharePoint Server 2007 can be deployed and configured in a wide variety of ways. As a result, there is no simple way to estimate how many users can be supported by a given number of servers. Therefore, make sure that you conduct testing in your own environment before you deploy Office SharePoint Server 2007 in a production environment.
Optimizations
This following sections discuss methods for improving farm performance by optimizing form templates and the database server.
Form template design optimizations
Optimize the first request (that is, the request to open the form) for form templates without onLoad events or business logic. Optimize the first request by delaying the creation of session state entry in the database until a POST occurs. Note that for such form templates, if the only POST was to close the form after Submit, the SQL session state will not be created. To apply this optimization, the form designer must set the Submit advanced setting to close the form after Submit. For more information about form template design optimizations, see the six-part blog series at Designing browser-enabled forms for performance in InfoPath Forms Services (https://go.microsoft.com/fwlink/?LinkId=129548).
If a scenario involves saving a form to a document library, it is better to submit the form to the library instead of saving it. A Submit operation triggers only one POST request or round trip, whereas a Save operation triggers two POST requests. The name of the form can be dynamically generated by using a rule or by using a control in the form.
To reduce user latency, we recommend that the form designer reduce the number of controls per view. For first-page view optimization, position controls that have a high resource cost, such as rich text fields, in subsequent views instead of in the default view.
Database server optimizations
- It is more important to have a 64-bit version of the Windows Server 2003 operating system on the database server than to have a 64-bit version of SQL Server database software. This is because the 64-bit Windows Server architecture provides better address allocation, and more memory is available to the SQL process. On the other hand, if physical memory on the database server is a performance bottleneck, consider using a 64-bit database server also. The recommended configuration for SQL Server 2005 is an 8-processor, 64-bit computer that uses the 64-bit version of Windows Server 2003.
Common bottlenecks and their causes
During performance testing, several different common bottlenecks were revealed. A bottleneck is a condition in which the capacity of a particular constituent of a farm is reached. This causes a plateau or decrease in farm throughput.
The following table lists some common bottlenecks and describes their causes and possible resolutions.
Bottlenecks in InfoPath Forms Services
| Bottleneck | Cause | Resolution |
|---|---|---|
Database contention (locks) |
Database locks prevent multiple users from making conflicting modifications to a set of data. When a set of data is locked by a user or process, no other user or process can modify that same set of data until the first user or process finishes modifying the data and relinquishes the lock. |
To help reduce the incidence of database locks, you can:
Methods exist to circumvent the database locking system in SQL Server 2005, such as the NOLOCK parameter. However, we do not recommend or support use of this method due to the possibility of data corruption. |
Database server disk I/O |
When the number of I/O requests to a hard disk exceeds the disk’s I/O capacity, the requests will be queued. As a result, the time to complete each request increases. |
Distributing data files across multiple physical drives allows for parallel I/O. The blog SharePoint Disk Allocation and Disk I/O (https://go.microsoft.com/fwlink/?LinkId=129557) contains much useful information about resolving disk I/O issues. |
Web server CPU utilization |
When a Web server is overloaded with user requests, average CPU utilization will approach 100 percent. This prevents the Web server from responding to requests quickly and can cause timeouts and error messages on client computers. |
This issue can be resolved in one of two ways. You can add additional Web servers to the farm to distribute user load, or you can scale up the Web server or servers by adding higher-speed processors. See Plan for availability (Office SharePoint Server) and Plan for redundancy (Office SharePoint Server) for more information. |
Estimating disk space requirements
The following sections provide tables that can help you estimate disk space requirements for this scenario. Disk space requirements for your hardware will vary greatly by server role and scenario. Disk space requirements are dependent upon the data to be stored in the content database, caching requirements, and the number and size of forms and form templates stored in the farm. Where possible in the following discussion, numbers in the formulas are based on disk space requirements that can be predicted, for example, the size of installation files.
First, estimate your disk space requirements by server role. Then, based on your planned topology, for cases in which server roles share the same physical server computer, add the disk space requirements for those roles. Finally, confirm that your hardware can support your disk space requirements.
Additionally, use best practices for SQL Server storage on database servers. For more information, see Physical Database Storage Design (https://go.microsoft.com/fwlink/?LinkId=78853&clcid=0x409). If more than one database server is implemented, apply the SQL disk space factor separately for each Web server.
Note
Operating system and program files should be stored separately from data files on a separate drive or a redundant array of independent disks (RAID).
Disk space requirements for database servers
Use the following table to calculate disk space requirements for database servers in your farm. If more than one database server is implemented, calculate this sum separately for each database server.
| Category | Description | Value |
|---|---|---|
Operating system files |
Disk space that is required for Windows Server 2008 Setup and system files. For more information, see Choosing a File System for the Installation Partition (https://go.microsoft.com/fwlink/?LinkId=78866&clcid=0x409). |
4 GB |
Paging file |
By default, the size of the paging file will be the same as the amount of physical memory. |
|
SQL Server installation files |
Disk space that is required for SQL Server Setup and program files. For more information, see SQL Server 2005 Standard Edition System Requirements (https://go.microsoft.com/fwlink/?LinkId=78870&clcid=0x409). |
425 MB |
Database log files |
Put the SharedServices_DB.ldf file on a different hard disk from the disks on which the SharedServices_DB.mdf file and the WSS Content_DB are located. Administrators may want to have a specific disk dedicated to log files because log files can become very large. Alternatively, configure the log files to recycle after reaching approximately 50 percent of the available disk space. Disk space for log files will vary based on log settings and the number of databases. For more information, see Physical Database Storage Design (https://go.microsoft.com/fwlink/?LinkId=78853&clcid=0x409). |
|
Configuration database |
The configuration database will generally not grow past this size. This is an estimated maximum size, not a hard limit. |
1.5 GB |
Content databases |
Put the SharedServices_DB.mdf file on the virtual disk that has the longest disk array and largest capacity. Estimate the initial volume of content that will be stored in content databases. Consider the following factors:
|
|
Future growth |
You should plan for double the amount of data that you expect your initial deployment to contain. Enter a number that is appropriate for your environment. |
|
Free space |
Leave at least 25 percent free space for each hard disk or volume. |
|
Total capacity |
Disk space requirements for Web servers
Use the following table to calculate disk space requirements for each Web server in your farm.
| Category | Description | Value |
|---|---|---|
Operating system files |
Disk space that is required for Windows Server 2008 Setup and system files. For more information, see Choosing a File System for the Installation Partition (https://go.microsoft.com/fwlink/?LinkId=78866&clcid=0x409). |
4 GB |
Paging file |
By default, the size of the paging file will be the same as the amount of physical memory. |
|
Office SharePoint Server 2007 installation files |
1.3 GB |
|
The .NET Framework version 3.5 |
60 MB |
|
Free space |
Leave at least 25 percent free space for each hard disk or volume. |
|
Total capacity |
Performance monitoring
To help you determine when you have to scale up or scale out your system, use performance counters to monitor the health of your system. Use the information in the following tables to determine which performance counters to monitor, and to which process the performance counters should be applied.
Web servers
The following table shows performance counters and processes to monitor for Web servers in your farm.
| Performance counter | Apply to object | Notes |
|---|---|---|
Processor time |
Total |
Shows the percentage of elapsed time that this thread used the processor to execute instructions. |
Memory utilization |
Application pool |
Shows the average utilization of system memory for the application pool. You must identify the correct application pool to monitor. The basic guideline is to identify peak memory utilization for a given Web application, and assign that number plus 10 to the associated application pool. |
Database servers
The following table shows performance counters and processes to monitor for database servers in your farm.
| Performance counter | Apply to object | Notes |
|---|---|---|
Average disk queue length |
Hard disk that contains SharedServices.mdf |
Average values greater than 1.5 per spindle indicate that the write times for that hard disk are insufficient. |
Processor time |
SQL Server process |
Average values greater than 80 percent indicate that processor capacity on the database server is insufficient. |
Processor time |
Total |
Shows the percentage of elapsed time that this thread used the processor to execute instructions. |
Memory utilization |
Total |
Shows the average utilization of system memory. |
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable content for Office SharePoint Server 2007.