Documentation Center

Troubleshooting the number of items that can be in transit

On the Content Manager side and on the Content Delivery side, you can configure how many items can be in transit. If the former exceeds the latter, publishing can become throttled.

Content Manager side

You can calculate the total number of publish transactions that can be sent to the Content Deployer by taking the sum of the threads per Transport Service. Each Transport Service has its own number of threads, configured in the Transport Service Workers element in the TransportPriorityPoolSize attribute.

Overall, the number of threads you need to have available per Transport Service is the total number of destinations to which you publish at any one time, multiplied by two, and with one thread extra.

You can find out the total number of destinations by checking all Publication Targets in all Target Types. Each Publication Target represents one or more destinations. So, for example, if you find out that users publish to 11 distinct destinations, your total number of Transport Service threads must be (2 * 11) + 1 = 23 threads.

Content Delivery side

On the receiving end, the Content Deployer also has a maximum number of items in transit that it can handle. This is the window size of the Deployer, configured in the Content Deployer configuration file. If the window size is set to 0 (default), the Deployer sets no limit on the number of items in transit.

To prevent throttling, ensure that the window size is equal to or larger than the total number of Transport Service threads configured on the Content Manager side. Do note that a bigger window size means a bigger load on the CPU of the deployment system.

It is possible for a Deployer to pick up input from multiple locations. This is the case if the Queue element in the Deployer configuration file has multiple Location subelements. Each Location element has its own window size, and so the total number of items in transit that this Content Deployer can handle is the sum of all window sizes of all pickup locations.

Tweaking the two settings

The Content Deployer communicates its window size(s) by placing a special file called meta.xml in its pickup location(s). The Transport Service can read this information and see if the number of items it is sending exceeds the number of items the Deployer can handle. If this is the case, the Transport Service gives any excess transactions the status Throttled in the Publishing Queue. Thus, if you see the Throttled status appear in the Publishing Queue, you are pushing content to the Deployer faster than it can handle it.

If this is a temporary problem, it will resolve itself: the Transport Service waits and retries the transaction. If the transaction is throttled again, it waits again (longer now) and retries again, and so on, until a maximum allowable interval has been reached. Eventually, publishing should slow down and all outstanding transactions will be completed.

If the problem is structural, however, more and more publish transactions will be given the Throttled status. Users who publish can see this information and alert you to the problem.