Estimate performance and capacity requirements for Word Automation Services in SharePoint Server 2010

Applies to: SharePoint Server 2010

This article contains capacity planning guidance for Word Automation Services. Use this article to help estimate hardware and Microsoft SharePoint Server 2010 farm requirements for Word Automation Services on topologies that are running SharePoint Server 2010.

In this article:

• Test farm characteristics

• Test results

• Recommendations

• Troubleshooting

Test farm characteristics

This section describes the dataset, workloads, hardware settings, topology, and test definitions that were used during the performance and capacity testing of Word Automation Services 2010.

Dataset

The dataset that was used for testing includes 384 unique, Open XML .docx files that contain the following kinds of Microsoft Word 2007 content:

• Text with direct formatting

• Content controls

• Images

• Tables

• Styles

• Fields

• OLE objects

• Hyperlinks

• Bookmarks

• Comments

• Citations

These files ranged from 20 KB to 8.8 MB and had an average size of 225 KB per file. Duplicates of these 384 files were used to create a library of about 20,000 documents. That library was then used as an input library for each test run.

Workload

Testing for Word Automation Services was designed to help develop estimates for how different farm configurations respond to changes in the following variables:

• Number of Word Automation Services-enabled application servers in the farm

• Number of active conversion processes per Word Automation Services-enabled application server

• Number of items in the Word Automation Services database

The specific capacity and performance figures presented in this article will differ 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 complete an initial system design, test the configuration to determine whether the system will support the factors in the environment.

Test definitions

This section defines the test scenarios for this article and describes the test process that was used for each scenario. For detailed information such as test results and specific parameters, see Test results.

Table 1 Test Definitions for This Article

Hardware, settings and topology

This section describes the hardware, settings, and topologies that were used in the tests.

Lab hardware

To provide a high level of test-result detail, several farm configurations were used for testing. Farm configurations ranged from one to seven application servers and a single database server that was running Microsoft SQL Server 2008 database software. All servers were 64-bit.

The following table lists the specific hardware that was used for testing.

Table 2 Lab Hardware Details for the Word Automation Services Test Topology

A dedicated front-end Web server was never used for testing. Instead the front-end Web server that was used to drive testing was also Application Server 1. This is common for a Word Automation Services-dedicated topology because SharePoint Server front-end Web servers are not used to process conversions. The only role of a front-end Web server is to create conversion jobs by way of a custom SharePoint Server solution, such as a custom Web Part. A front-end Web server might have to remain responsive for a SharePoint Server solution to work correctly.

For the Word Automation Services test farm, a simple C# application was used on front-end Web Server–Application Server 1 to occasionally create conversion jobs for testing. Maintaining the responsiveness of the front-end Web server was not a concern for this farm. Therefore, it was appropriate to use the front-end Web server as an application server.

Topology

Diagram 1 – Word Automation Services test farm topology

Test results

The following tables show the test results of Word Automation Services in SharePoint Server 2010. For each group of tests, only certain specific variables are changed to show the progressive effect on farm performance.

Throughput scale

Effect of active conversion processes on throughput

The two tests in the following table show how the throughput of Word Automation Services increases as the number of active conversion processes is increased gradually on a single application server. Data is shown for two output formats: Open XML (.docx) and PDF. The Open XML conversions provide a baseline throughput for comparison against other output formats, and the PDF conversions provide an example of a more-typical conversion throughout.

Table 3 Example Throughput of an Eight-Core Application Server As Active Conversion Processes Are Added

There is a decrease in throughput for PDF that is encountered when Word Automation Services uses six active conversion processes instead of four. This is due to a per-server limitation in Word Automation Services when it converts to PDF (or XPS). In contrast, the throughput of Open XML does not have this limitation and continues to increase until eight active conversion processes are used. However, Open XML encounters another, more common limit when the number of active conversion processes exceeds the number of processing cores on the server. (In this case, that number is eight cores.)

The unusually small improvement in throughput for Open XML when you are using six active conversion processes versus four active conversion processes is a typical variation for Word Automation Services. This demonstrates how throughput can vary from expectations for a given configuration.

The following diagram is a graph of this data.

Example throughput of an eight-core application server as active conversion processes are added

The 16, 24, and 32 active conversion process numbers demonstrate that having more active conversion processes than there are processing cores adversely affects the throughput of an application server. Conversion items may also be more likely to fail intermittently when Word Automation Services uses an unsupported number of Total Active Conversion Processes for a given application server.

The results of this test illustrate the following important effects of the number of active conversion processes on throughput:

• The best improvements of throughput for conversion to PDF occur when you increase from one active conversion process to three active conversion processes per server. PDF throughput begins to decrease as approximately four or more active conversion processes are used on any server that has four or more processing cores. This is a limitation of Word Automation Services. The same limitation also applies to XPS.

• The throughput improvement for other formats, such as Open XML, can scale up very well to n active conversion processes, where n is the number of processing cores on the application server. However, the recommended maximum number of total active conversion processes for application servers is n-1. This is explained more in the Recommendations section.

Effect of an increase in the number of application servers on throughput

The two tests in the following table show how the throughput of Word Automation Services increases as the number of application servers is increased gradually. The number of total active conversion processes was set to eight for the farm. Data is shown for two output formats: Open XML and PDF. The Open XML conversion throughput is a good representative of most output formats while the PDF conversion throughput is better for representing both PDF and XPS.

Table 4 Example Throughput of Farm As the Number of Application Servers Is Increased

The following diagram shows that the increase in throughput for both PDF and Open XML remains generally linear for each additional server added.

Chart 2 – Example throughput of farm as the number of application servers is increased

Table 5 Percent Increase for Single-Server Throughput

Table 6 Percent Throughput Increase for Z-1 Throughput

Table 5 shows the percentage increase of throughput that is compared to the throughput of a single application server. For example, the 1x4 topology (four application servers) has a 102.11 percent improvement of throughput compared to the 1x1 topology (a single application server).

Table 6 shows the percentage increase of throughput that is compared to the throughput of the previous topology listed in the table. For example, the 1x4 topology has four application servers. Therefore, Z = 4. If Z = 4, then Z-1 = 3, and the Z-1 topology is the 1x3 topology. The 1x4 topology has a 41.99 percent improvement of throughput compared to the 1x3 topology.

These numbers are only a sample of how throughput might increase in a given production deployment of Word Automation Services. Some variations that appear in these tables may not be typical for other SharePoint Server farms.

The number of total active conversion processes was set to eight. Therefore, the PDF results are likely less than what would be expected from these application servers if they had the number of total active conversion processes set to avoid the decrease in throughput for PDF that is due to a per-server limitation in Word Automation Services (as shown in Table 3). The PDF throughput numbers in Table 4 could likely be improved significantly by setting the number of total active conversion processes to four. However, this would undoubtedly decrease the throughput numbers for Open XML, as shown in the results in Table 3. The important characteristic of throughput that can be learned from these observations is that there is a trade-off to consider when you select a value for the Total Active Conversion Processes setting. The recommended Word Automation Services settings in the Recommendations section take this trade-off into consideration by providing two sets of recommended settings.

This data demonstrates that scaling out is a great way to increase Word Automation Services throughput for any output format. The linear improvement in throughput that is shown here is unlikely to increase infinitely as a topology grows. Certain bottlenecks will emerge. For example, the SQL Server computer will eventually reach capacity.

SQL Server database file size

Database size

The Word Automation Services database requires between 1.58 to 0.15 KB of disk space per conversion item in the database, as shown in the following table.

Table 7 .Mdf File Size for a Varying Number of Conversion Items

What you learn from this data is that the size of the .mdf file increases at an eventual rate of about 0.15 KB for each conversion item that is added to the Word Automation Services database. Approximately the first 50,000 conversion items are an exception. However, the total size of the .mdf file is clearly manageable when the number of conversion items is this small.

In general, we recommend that the Word Automation Services database not grow larger than a size of 2 million conversion items. Otherwise, the performance of some Word Automation Services solutions may decrease as the database grows.

Deleting items from the Word Automation Services database

Approximately 0.2 to 0.5 KB of disk space is used by Word Automation Services in the SQL Server .ldf file for every item deleted from the database. SQL Server uses the .ldf file to maintain recovery data for the Word Automation Services database.

Table 8 .Ldf File Size for a Varying Number of Conversion Item Deletions

The size of the .ldf file expands at certain intervals as specified by the autogrowth settings of SQL Server. More information about the growth of the .ldf file can be found in the following article: A transaction log grows unexpectedly (https://go.microsoft.com/fwlink/p/?LinkId=217307).

If left unattended for long, the .ldf file can grow until the SQL Server computer runs out of disk space. Decreasing the size of the .ldf file periodically should be considered part of routine maintenance for any production farm. Information on how to handle an overly large .ldf file can found in the following articleRecover from a full transaction log in a SQL Server database.

Recommendations

Single-server farm

Word Automation Services can be run on a single server installation of SharePoint Server. This server acts as the front-end Web server, the application server, and the database server for the Word Automation Services database and various SharePoint databases.

However, in a production environment, we strongly recommend against using a single-server farm. Word Automation Services, SharePoint Server, and SQL Server will compete for resources, which can result in inconsistent performance from Word Automation Services.

Basic Word Automation Services farm

A basic Word Automation Services farm is composed of two servers: a single server to act as both front-end Web server and application server, and a second server to act as an instance of SQL Server for SharePoint Server and Word Automation Services. Such a configuration should be considered the minimum topology for a production Word Automation Services farm. Expanding beyond this basic topology is explained in Advanced topologies.

Diagram 2 – Simple Word Automation Services farm topology

Advanced topologies

To increase the capacity and performance of the basic Word Automation Services farm, you can either scale up by increasing the capacity of existing application servers, or scale out by adding additional servers to the topology. This section describes the general performance characteristics and recommended settings of several topologies that combine these two strategies in various configurations. Not all possible topologies are represented; the topologies described here are select examples.

Scaled-out topology 1: more application servers

A scaled out topology increases the capacity of a farm by adding more application servers to the farm. As the test results in Table 4 show, this strategy is effective for increasing a farm’s capacity for any output format. Scaling out is a good next step when existing servers that you have scaled up no longer benefit throughput of Word Automation Services.

Diagram 3 – Scaled-out Word Automation Services farm topology with three application servers

Scaled-out topology 2: reducing the SQL Server impact

Word Automation Services maintains its own SQL Server database. In a basic Word Automation Services farm, both the Word Automation Services database and the databases that are associated with SharePoint Server exist on the same physical instance of SQL Server. Word Automation Services affects both the databases that are associated with SharePoint Server (for example, input to and output from the content database), and the Word Automation Services database (for example, updating the status of a conversion item when a conversion is completed successfully).

To prevent a shared database server from becoming a bottleneck for both Word Automation Services and SharePoint Server, a separate physical database server can be created to host the Word Automation Services database. This can improve Word Automation Services throughput and reliability if a shared database server is a bottleneck for a farm.

Diagram 4 - Word Automation Services farm with dedicated SQL Server topology

A single database server is typically not a bottleneck for small farms, especially if Word Automation Services is the only service being used.

Scaled-up topology: dedicated Word Automation Services farm

A dedicated Word Automation Services farm, as shown in the following diagram, is the best topology for maximizing Word Automation Services throughput. This kind of topology involves increasing the capacity of individual servers in the farm by configuring Word Automation Services to fully take advantage of application server resources. Several key service settings must be configured correctly to achieve this without experiencing service limits.

Diagram 5 – An example of a dedicated Word Automation Services farm topology

Performance can benefit by running Word Automation Services solutions on a front-end Web server that is separate from the dedicated application servers in the farm if the solution that is driving Word Automation Services is used to create many small conversion jobs. In such a case, a dedicated front-end Web server helps ensure that the solution is responsive, even when the application servers are under load. The previous diagram shows an alternative topology where the front-end Web server is also an application server in such a way that it is still used to process conversions. Such a topology could be ideal if the solution that drives Word Automation Services creates only a few large jobs occasionally.

Dedicated Word Automation Services farms should typically use the following settings:

For PDF and XPS output formats

• Total Active Conversion Processes is set to the lower of the following values: n-1, where n is the number of available processing cores in each server, or 4

  • Example: This setting would be 4 when the farm applications servers have two quad-core CPUs, because 4 is a lower value than n-1, which is 7.

    Note

    As shown in Table 3, performance limits of the service when it converts documents to a fixed output format such as PDF greatly limit the scale-up potential of individual servers for PDF and XPS. Four cores is typically the best Total Active Conversion Processes setting for maximizing throughput on an application server when outputting to PDF or XPS. Increasing the value for this setting will actually decrease throughput for PDF and XPS.

• Frequency with which to start conversions (minutes) is set to 1 minute.

• Number of conversions to start (per conversion process) is set to 30.

  Note

  This value enables a maximum RPS of up to 0.5 conversions per second for each active conversion process in the farm. As shown in Tables 3 and 4, this is a reasonable RPS to target so that a maximum possible throughput for a farm is achieved for the PDF and XPS output formats.

For .docx files, .doc files, and other output formats

• Total Active Conversion Processes is set to n-1 where n is the number of available processing cores in each server

  • Example: This setting would be 7 if the farm application servers have two quad-core CPUs.

  • Note: It is recommended to never set Total Active Conversion Processes to any value larger than n-1. Some reliability and responsiveness problems may start to occur when a larger value is used.

• Frequency with which to start conversions (minutes) is set to 1 minute.

• Number of conversions to start (per conversion process) is set to 72.

  Note

  This value enables a maximum RPS of up to 1.2 conversions per second for each active conversion process in the farm. As shown in Table 4, this is a reasonable RPS to target in such a way that a maximum possible throughput for a farm is always achieved for non-PDF and XPS output formats.

Throttled topology: production SharePoint farm with shared application servers

Because an active conversion process will use at most one processing core at a time, you can throttle Word Automation Services by setting the Total Active Conversion Processes setting to significantly less than the total number of available processing cores for each application server. Throttled application servers in this topology, as shown in the following diagram, will always have processing cores free for other tasks or services, which generally helps prevent application servers from becoming unresponsive when Word Automation Services is under load.

Diagram 6 – An example of a production farm topology with shared application servers running Word Automation Services

By default, Word Automation Services is throttled with a Total Active Conversion Processes setting of 1. This is expected to be too conservative for most Word Automation Services deployments, and the following settings should be used on a typical throttled topology:

For PDF and XPS output formats

• Total Active Conversion Processes is set to the lower of the following values: (n/2)-1 where n is the number of available processing cores in each server, or 4.

  • Example: This setting would be 3 when the farm’s application servers have two quad-core CPUs because (8/2)-1 is 3, and 3 is lower than 4.

  • Example: This setting would be 4 when the farm’s application servers have four quad-core CPUs, because 4 is lower than (16/2)-1, which is 7.

  Note

  By leaving a single processing core unused, the application server can remain more predictable even when the Word Automation Services timer job is executing, which can temporarily dominate an additional processing core. This is true for all topologies. These settings basically restrict Word Automation Services to a peak CPU utilization of 50 percent. To decrease the peak CPU utilization of the service even more, decrease the value of this setting to (n/2)-2, (n/2)-3, and so on.

• Frequency with which to start conversions (minutes) is set to 1 minute.

• Number of conversions to start (per conversion process) is set to 30.

  Note

  This value enables a maximum RPS of up to 0.5 conversions per second for each active conversion process in the farm. As shown in Table 4, this is a reasonable RPS to target to ensure that suitable throughput is achieved.

For .docx files, .doc files, and other output formats

• Total Active Conversion Processes is set to (n/2)-1 where n is the number of available processing cores in each server.

  • Example: This setting would be 3 when the farm’s applications servers have two quad-core CPUs.

    Note

    By leaving a single processing core unused, the application server can remain more predictable even when the Word Automation Services timer job is executing, which can temporarily dominate an additional processing core. This is true for all topologies. These settings basically restrict Word Automation Services to a peak CPU utilization of 50 percent. To decrease the peak CPU utilization of the service even more, decrease the value of this setting to (n/2)-2, (n/2)-3, and so on.

• Frequency with which to start conversions (minutes) is set to 1 minute.

• Number of conversions to start (per conversion process) is set to 60.

  Note

  This value makes it possible to achieve a maximum RPS of up to 1.0 conversions per second for each active conversion process in the farm. As shown in Table 4, this is a reasonably conservative RPS target for output that is not in PDF or XPS formats.

  Note

  Setting this value to 60 instead of 72 makes it more likely for application servers to have all the processing cores available for a short time (several seconds) per unit of time, as set by the Frequency with which to start conversions (minutes), which in this case is 1 minute. This can be helpful, depending on the needs of the farm. Lowering this setting will also free all application server processing cores for even longer, but at an additional cost to throughput.

Mixed topology: production SharePoint farm with a mix of Word Automation Services-enabled application servers and other application servers

A mixed topology of Word Automation Services-enabled application servers and non-Word Automation Services-enabled application servers is the best way to achieve high Word Automation Services throughput without affecting the performance of other SharePoint services. The advantages of a mixed farm are as follows:

• Throughput is increased by using dedicated Word Automation Services servers.

• Other services that run on non-Word Automation Services-enabled application servers are minimally affected by Word Automation Services.

The disadvantages of using a mixed farm are as follows:

• More physical servers may be required compared to using a shared farm or dedicated farm.

• All Word Automation Services application servers will use the same settings.

There are two basic configurations for mixed farms:

• Non-Word Automation Services application servers are mixed with shared, throttled Word Automation Services-enabled application servers.

• Non-Word Automation Services application servers are mixed with dedicated Word Automation Services application servers that have been configured to take full advantage of application server resources.

A mixed topology might resemble the topology shown in the following diagram.

Diagram 7 - An example of a production farm topology with application servers that are dedicated to Word Automation Services

The Word Automation Services-enabled servers in a mixed farm can be configured similarly to either the shared application servers in a Throttled topology or the dedicated application servers in a Scaled-up topology to achieve the same throughput of either of those topologies.

Estimating throughput targets

Use the information in this section to determine the target throughput of a given topology with specific settings.

Throughput in conversions per minute per application server

(Total Active Conversion Processes * Number of conversions to start (per conversion process)) / Frequency with which to start conversions (minutes)

Notes:

• The result of the previous equation, if converted to conversions per second per active conversion process, should not exceed 1.2 for non-PDF or non-XPS output formats, or 0.5 for PDF or XPS output formats. Exceeding these values could lead to decreased throughput and an increase in conversion failures.

• If the Frequency with which to start conversions (minutes) is increased (that is, the Word Automation Services timer job will run less often) and the total throughput of the farm has to remain the same, the Number of conversions to start (per conversion process) should be increased in direct proportion to Frequency with which to start conversions (minutes).

  For example, a SharePoint administrator wants the Word Automation Services timer job to run less frequently, but she also wants the throughput of Word Automation Services to remain unchanged. The settings that are shown in the following table will achieve this goal.

  	Original settings	New settings
  Frequency with which to start conversions (minutes)	1 minute	10 minutes
  Number of conversions to start (per conversion process)	72	720

  Note

  Total Active Conversion Processes should not be changed in proportion to Frequency with which to start conversions (minutes).

Throughput in conversions per minute for the whole farm

• For PDF and XPS output formats:

  Multiply the result of the Throughput in conversions per minute per application server equation by the number of application servers that have Word Automation Services enabled. The final result is consistent with the data in Table 5.

• For other output formats:

  Multiply the result of the Throughput in conversions per minute per application server equation by the number of application servers that have Word Automation Services enabled. Then, multiply that result by 0.65. The final result will reflect the data shown in Table 5.

Troubleshooting