Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Windchill Replication performance when Master sites is https


Windchill Replication performance when Master sites is https


I have a Windchill 10.1 M040 System running on Windows Server 2008r2 x64 hosts - Master https and Replica's configured for http.

Replication from Master to Replica's goes via https over the WAN and hence can't be accelerated (much) by our WAN accelerators as the packets are encrypted.

I have found that the replication performance to the replica's is between 3-10Mb/s depending on the replica site location and link speed/latency.

In order to test this further with a best case scenario, I have also build a test replica server on the same Network LAN segment (ie not even a WAN link) as my https Master server, and I am seeing https replication from the Master to the Replica maxing out at 11Mb/s and averaging at about 5Mb/s.

I am rather surprised by the performance - does anyone else have any performance figures they can share to see if there is something wrong with my system, or is this sort of speed expected.




Did anyone respond to you on this yet? I wouldd be interested in the response if you received one offline. thanks.

Also do you have any best practices, do's and don't's and the impacts of certain configurations? I.E. Public WAN vs Private WAN what occurs with latency or dropped connections, etc...?


1/ you could speed up replication over WAN with https by installing your certificates on the WAN accelerators. This wikk allow your WAN accelerator to decrypt content for indexation. Check with network admin or WAN accelerator provider.

2/ you may speed up replication on the LAN using // replication (replication is driven by queue)

Hope this help


I don't think there is something wrong with your system. The performance depends on many things and there is no easy answer. Depending on network speed, network devices, file system performance, number of methodservers (parallelism), file size and other things your results may vary widely.

We are operating a system with eight Linux Clusternodes and fourteen remote FileServers all over the world. As for the reference value we are using wget as a simple way to simulate download from our master system. We use this to monitor network performance to our remote sites. All communication is https.

First a site near to the system:



Now a site with medium latency:


We also did some testing for best case values with wget of a 141 MB file between the CADWorkers and the MethodServers. This gave a reference value for huge files of 62 MB/s maximum for transfer within the LAN.

The next value was up to 34 MB/s for systems in the Intranet of the datacenter, now with Routers and Firewall involved.

These values may not reflect the actual performance for the PDMLink system but they are easy reproducable and may serve as a reference value for comparison.


Hi Michael,

May I ask what software you use for data collection, analysis and then graphical presentation of results?

I think I ought to set up some monitoring solution for our environment so that we can more easily see if the network links are performing as expected.



Hi Gary,

these diagrams were created with cacti ( which is a simple and unexpensive opensource solution for network graphing.

Cacti requires that the following software is installed on your system.

  • RRDTool 1.0.49 or greater, 1.4+ recommended
  • MySQL 5.x or greater
  • PHP 5.1 or greater
  • Web Server that supports PHP e.g. Apache or IIS



I had forgotten all about this post in the hours of debugging and testing that I have been doing on this matter recently 🙂

I can now correct and update my original post with my recent findings in the hope that this might help others with similar questions.

Firstly a clarification, I consider "Mb/s" to be Mega Bits/sec and "MB/s" as Mega Bytes/sec.

Secondly a correction - I stated in my original post that a Replica Server that I built on the same LAN segment as my HTTPS Master server only replicated at a peak line speed of 11Mb/s and an average of 5Mb/s - this was an error on my part. I miss-calculated this by a factor of 10 as it was a 10Gb/s link rather than a 1Gb/s link - DOH!!

Once I realised this, I could see that the LAN replication was running at 110Mb/s Peak and 50Mb/s average line speed, which is much more reasonable. If you also consider the Master and Replica compress/uncompress the data with GZIP as it goes over the line, the resulting Vault File size performance is even higher than this - resulting in a real world replication of about 75Mb/s average over a long replication period.

That then made it obvious that there was something terribly wrong with the WAN performance compared to what we were seeing over the LAN. This was finally traced back to a hardware fault on our Juniper WXC WAN Accelerator device and some further miss-configuration issues.

I am now seeing HTTPS WAN Replication performance of up to 30Mb/s average line speed with our current (old) Juniper WAN accelerators - maybe about 50Mb/s Vault File Transfer speeds with the GZIP compression - which is much more like I was expecting between sites located in the EU.

Obviously replication from UK to China, runs a lot slower - about 10Mb/s average line speed with our accelerator environment, but this runs at about 1Mb/s average without the WAN accelerator so it is doing a good job - mainly it seems in reducing the SSL handshake "chatter", as it cannot compress or cache the (already compressed) and encrypted HTTPS packets.

It is no longer possible for us to purchase the license for our Juniper WXC's to allow us to put the Master Server's HTTPS certificate into the WAN accelerator so that it could decrypt and compress the replication stream as the boxes are now EOL, but we should be implementing a new Riverbed based WAN acceleration environment soon that seems to perform very well from testing other data transfer types and this does come with the ability to load HTTPS certificates - we would then turn off the GZIP compression/decompression on the Windchill Master and Replica servers so that the Riverbed can un-encrypt, compress and perform network sequence cacheing on the data stream.

Happy Days