HTTP Deployer displays slow transport throughput on high latency networks

Question

I've got an unusual issue and I was hoping someone might be able to shed some light on it. The setup is as follows:

• Publisher role in Europe (Transport Service).
• Three target Content Deployers with one in Europe, one in the US, and one in the Asia Pacific region (three different machines in three different geographic regions).
• The Content Deployers need to support two different configurations (i.e. two different Brokers and wildly differing config\libs) and so are HTTP Deployers rather a single Deployer Windows service - as per the usual SDL best practise.

The issue is the transport time during the HTTP POST phase of publishing and is primarily affecting the publishing to Asia Pacific. I'd expect it to be slower than EU/US publishing but certainly not at the level I'm seeing. After analysing the throughputs I can confirm:

• EU transport speed during HTTP POST phase of publishing = wire speed
• US transport speed during HTTP POST phase of publishing = 1.3 mbps
• AP transport speed during HTTP POST phase of publishing = 0.3 mbps

I can confirm this is not a bandwidth issue between the regions as any other data transfer method to either the US or AP regions reaches 50-100 mbps depending on file size. The methods tried are via FTP PUT/GET and SMB file share copy to/from.

When trying FTP publishing to a single target Deployer Windows service the transport phase of publishing improves by a factor of anything up to x50-100 (yes, that is 50 or 100 times the throughput observed when compared to using an HTTP Deployer).

For your info the latency we see is:

• EU - 1ms
• US - 75ms
• AP - 350ms

Is there a fundamental limitation of the HTTP Deployer method in high latency situations such as this? I'm hoping someone might have some experience with a similar architecture.

The above brings me on to another question. Is it possible to implement FTP targets instead using two different Deployer Windows service on the same Tridion Content Delivery machine (and therefore two different configurations - Broker/config/lib). There used to be a way back in the 2009 days as far as I'm aware, but is there anything that can be done with 2011 SP1?

Many thanks for your help.

Scott

Answer 1

There is no known bandwidth limitation on the Http Deployer itself that I know of. That said, if the network latency for other protocols is a lot lower compared to HTTP traffic, I would look in the following places first:

1. Http Proxy servers and / or firewalls standing in between the source and the destination. It may very well be that bandwidth throttling is enabled for http connections (to prevent users from downloading too many large binaries). Should this be the case, an exception should be made for deployer traffic.

2. Check on the receiving web server whether throttling is turned on and whether the server can actually handle large amounts of traffic.

That said, it's perfectly possible to use multiple protocols for one or more publish targets. If you have one publish target with multiple destinations you could do this:

Publish Target A:

• Destination EU: HTTP(s)
• Destination US: HTTP(s)
• Destination AP: (S)FTP

If you have one publish target for each destination, you can configure a protocol that you need for each Publish Target, which will then have one destination configured each.

Also, bear in mind you have to have all the protocols you need enabled in the Transport Service.

Finally, to answer your last question: it is possible to run multiple Deployer Services on the same machine. To do this, you have to start up each deployer service with its own lib and config directory, which you can read about in Rute's post.