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

Test name	Test description
Throughput scale	Create a document library in SharePoint Server and populate it with some number of valid Open XML files (.docx). Create and start a conversion job that uses the library from step 1 as an input library. When the conversion job is finished and all conversion items have succeeded or failed, use the results in the Word Automation Services database to determine the overall throughput of the service during the conversions.
SQL Server database file size	Create a document library in SharePoint Server and populate it with some number of valid Open XML files. Start and cancel conversion jobs to populate the database. It is not necessary for the conversion jobs to be completed. Record the size of the database .ldf and .mdf files.

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

Detail	Front-end Web Server–Application Server 1	Application Servers 2-7	Database server
Role	Front-end Web server–application server (shared)	Application server (dedicated)	SQL Server cluster (one computer)
Processors	2px4c @2.33 GHz	2px4c @2.33 GHz	4px4c @3.2 GHz
RAM	8 GB	8 GB	16 GB
Operating system	Windows Server 2008 SP2 x64	Windows Server 2008 SP2 x64	Windows Server 2008 SP2 x64
Storage and geometry (including. SQL Server disks configuration)	6 disks * 590 GB	6 disks * 590 GB	6 disks * 460 GB
Number of network adapters	2	2	2
Network adapter speed	1 gigabit	1 gigabit	1 gigabit
Authentication	NTLM	NTLM	NTLM
Software version	4762.1000	4762.1000	SQL Server 2008
Number of SQL Server instances	Not applicable	Not applicable	1
Load balancer type	NLB	NLB	Not applicable
ULS logging level	Medium	Medium	Medium

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

Active conversion processes	Open XML	PDF
1	2.72	1.13
2	4.65	1.78
3	5.92	1.99
4	7.02	2.00
6	7.73	1.87
8	9.45	1.64
16	7.91	1.41
24	8.06	1.37
32	7.71	1.37

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

Topology	Open XML	PDF
1x1	9.5	1.64
1x2	17.3	3.25
1x3	23.1	4.81
1x4	32.8	6.52
1x5	39.7	7.87
1x6	45.9	9.50
1x7	52.1	11.48

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

Topology	Open XML	PDF
1x1	Not applicable	Not applicable
1x2	82.11	97.57
1x3	61.05	95.30
1x4	102.11	103.66
1x5	72.63	82.21
1x6	65.26	99.05
1x7	65.26	120.54

Table 6 Percent Throughput Increase for Z-1 Throughput

Topology	Open XML	PDF
1x1	Not applicable	Not applicable
1x2	82.11	97.57
1x3	33.53	48.24
1x4	41.99	35.40
1x5	21.04	20.73
1x6	15.62	20.69
1x7	13.51	20.86

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

Items added	.Mdf file size (KB)	KB per item
2,304	3,648	1.58
4,608	3,648	0.79
23,040	6,720	0.29
46,080	10,048	0.22
230,400	37,952	0.16
460,800	72,000	0.16
1,152,000	174,400	0.15
2,304,000	345,408	0.15
3,456,000	515,392	0.15
4,608,000	685,376	0.15
11,520,000	1,707,328	0.15
23,040,000	3,429,568	0.15

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

Items deleted	.Ldf file size (KB)	KB per item
2,304	1,856	0.56
4,608	2,624	0.44
11,520	2,624	0.18
23,040	2,624	0.09
46,080	20,416	0.43
69,120	20,416	0.29
115,200	39,936	0.34
172,800	53,248	0.30
207,360	53,248	0.25
218,880	53,248	0.24
228,096	53,248	0.23
230,400	53,248	0.23

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

Bottleneck or issue	Cause	Resolution
The throughout when it converts to PDF or XPS does not improve with more than 3 or 4 active conversion processes even when more processing cores are available.	Word Automation Services is limited in how fast it can convert files to PDF or XPS on a single application server. Specifically, Word Automation Services throughput cannot be increased by scaling up beyond 3 or 4 active conversion processes per application server. Adding more active conversion processes per application server will actually decrease the performance of the service when it converts to PDF or XPS format.	If increasing the throughput of Word Automation Services is necessary for conversions to PDF and XPS, even if active conversion processes per application server is set at 3 or 4, then adding additional application servers will yield almost a-100 percent increase in throughput, given the same computer specifications. Also, if the number of active conversion processes per application server is set higher than 4, changing this setting to 4 will likely increase throughput by a small margin. However, setting active conversion processes per application server to 4 may significantly decrease throughput for other output formats. If converting to PDF or XPS is a primary requirement, then it could be more cost effective not to use dedicated Word Automation Services application servers. Shared servers can be used instead so that spare processing cores are available for other farm services.
Conversion items begin to fail more often after you change the settings for Word Automation Services.	The settings of Word Automation Services can easily be set to push the service past its practical limits. Doing so will likely result in: Less overall throughput Conversion items that fail more often	Follow these simple rules to help correct or prevent either of the previously listed symptoms: Never set Total Active Conversion Processes to be more than n-1, where n is the number of processing cores of the application server. Never set Number of conversions to start (per conversion process) to be more than what is suggested in Scaled-up Topology: A Dedicated Word Automation Services Farm for the desired output formats unless Frequency with which to start conversions (minutes) is also adjusted (in direct proportion) in such a way that the resulting throughput target remains the same.
Other services are less responsive after you change the settings for Word Automation Services.	An active conversion process will at times fully take advantage of a processing core on the application server. An application server configured as recommended in Scaled-up Topology: A Dedicated Word Automation Services Farm, can utilize most of the CPU resources during the conversion, because the Word Automation Services timer job also runs on its own core periodically. If other services such as Excel Web Services or Microsoft Office Web Apps require CPU resources from such an application server, there could be an unacceptable wait time that results in a perceived latency for those other services.	Follow these steps to decrease the effect of Word Automation Services on other services: Throttle the Total Active Conversion Processes for Word Automation Services to the level recommended in Throttled Topology: A production SharePoint Farm with shared application servers. Add application servers that are not used by Word Automation Services but are usable for other services, adopting a topology similar to that described in Mixed topology: production SharePoint farm with a mix of Word Automation Services-enabled application servers and other application servers.
Sometimes conversion items fail with error code 3 when the farm was busy, offline, or undergoing maintenance for part of a day or more.	Word Automation Services generally requires that conversion jobs added to the Word Automation Services queue database be fully processed within 24 hours of being submitted. If conversion items for a conversion job are not finished within 24 hours, then the conversion item could fail with error code 3. The error message would read: “The file could not be downloaded from the input library because the supplied user permissions expired before the file could be retrieved. This likely indicates that the system is under heavy load. Please try resubmitting the job, and contact the system administrator if the error reoccurs."	If users are consistently seeing this error and the farm was not offline for a significant time, some conversion jobs are likely taking longer than 24 hours to complete, probably because the farm is either misconfigured or its usage far exceeds its capacity. This behavior indicates that you should increase the capacity of the farm. This involves either increasing the Total Active Conversion Processes (up to n-1, where n is the number of processing cores on each application server) or, if you cannot do this, adding more application servers to the farm that Word Automation Services can use. The latter could involve merely enabling Word Automation Services on application servers that otherwise have excess capacity, or it may involve adding more physical servers to the farm. If you increase the capacity of the farm, make sure that the settings for Word Automation Services are configured correctly as described in either Scaled-up Topology: A Dedicated Word Automation Services Farm or Throttled Topology: A production SharePoint Farm with shared application servers.
The execution time of a Word Automation Services solution takes progressively longer to run as the service runs.	The execution times of the following Word Automation Services Object Model methods scale with the number of items in the Word Automation Services database: ConversionJob.GetAllActiveJobs ConversionJob.GetAllJobs	In general, we recommend that the Word Automation Services database not grow larger than a size of 2 million conversion items. Delete some conversions items from the database to resolve this problem.
Throughput performance of Word Automation Services does not continue to improve by scaling out the number of application servers.	If adding more application servers to the farm no longer improves throughput, this could be an indication that the instance of SQL Server where the Word Automation Services database resides is at capacity. The Word Automation Services SQL Server impact for each WAS Action is as follows:   Word Automation Services action RT per call Additional RT per item Notes ConversionJob.AddFile 11 0 Low SQL Server IOps ConversionJob.AddFolder 9 2 Despite the increase in SQL Server RT versus AddLibrary, this OM call is generally faster to execute than AddLibrary. Low SQL Server IOps ConversionJob.AddLibrary 4 2 Low SQL Server IOps ConversionJob.Start 3 0 Low SQL Server IOps ConversionJob.Refresh 1 0 Low SQL Server IOps ConversionJob.CancelJob 1 0 Low SQL Server IOps ConversionJob.GetAllActiveJobs 1 0 SQL Server IOps scale up with the number of jobs in the Word Automation Services DB. ConversionJob.GetAllJobs 1 0 SQL Server IOps scale up with the number of jobs in the Word Automation Services DB. ConversionJob.GetItems 2 0 Low SQL Server IOps Each Timerjob run 2 1 Low SQL Server IOps Some calls have a constant overhead in SQL Server round trips per action and additional SQL Server round trips per action depending on the number of conversion items involved. This information can be helpful for both developers who plan to create custom solutions for Word Automation Services deployments and farm administrators who must plan for the SQL Server effect of using Word Automation Services.	If the Word Automation Services SQL Server database resides on the same server as other active databases that use the Word Automation Services SQL Server database, its own physical server should remove SQL Server as a bottleneck for most farms.
After scaling out a farm, the timer job does not appear to finish before its next scheduled run.	The execution time of the timer job for Word Automation Services will scale linearly with the number of Word Automation Services–enabled application servers in the farm. It is possible that the timer job will take longer than one minute to complete its run.	No action is needed if this occurs. SharePoint Server will not begin a scheduled timer job run if the previous run is still executing.