I am wondering if anyone else sees the same behavior that I have. A company has multiple sites around the world, but the connection where it was most obvious was a WAN connection between the US and Malaysia. There is a 30Mb pipe and a 250ms ping time. However, Windchill file transfers would never go faster than 127kB/sec. It was especially painful because the congestion on the network line would often not exceed 30%, yet Windchill was just using a small portion of what was available.
Using Wireshark for network troubleshooting it became obvious that the throughput was quite constrained. The network adapter would put two 16kB packages on the WAN, then wait 250ms for an ACK before sending additional data. At no point did it try to put out additional packets, even though the negotiated window was 130kB.
If you look in <Windchill>\HTTPServer\conf\extra\additions.conf you will find these lines:
# At least on Windows with high bandwidth, high-latency connections this
# setting speeds downloads. It should not hurt in other cases.
#
# [Note that stock Apache 2 does not support this option on Windows at the
# time of this writing. Support for this has been patched into this Apache
# binary.]
#
SendBufferSize 16384
The result of this line is that Apache will send two 16kB chunks of data, then do nothing until it received an acknowledgement. It would send out this size of data regardless of whether the network thought it wanted less or could take more. In the days when the max window size was 64kB, and often negotiated much smaller, this would result in an improvement in performance. Now many (most?) WAN connections can accommodate much more than 16kB or 32kB of data "in flight", and this can become a performance hindrance.
Commenting out SendBufferSize line, the throughput increased from 127kB/sec to 1.5MB/sec. Essentially, the tcp transfer was able to make use of the majority of the available bandwidth to the remote site. Servers on both sides were Windows 2008 R2, and Apache was configured for HTTPS and file compression. There are Riverbed Steelhead devices in the path, but the Windchill traffic was bypassed as they were not loaded with the server certs to allow them to accelerate HTTPS traffic.
I believe the setting might have been appropriate in the not so distant past, but you might find that this is now a constraint on your Windchill data throughput.
If you have slow replication performance or slow file transfers to clients you might want to try commenting out this line and restarting Apache.
