I have now heard several ideas on how this actually works, so I really would like to hear from you guys how it really works.
When checking a document back into to ProjectWise ‘through’ a Caching Server, then the document is checked all the way back into the Integration Server, bypassing the Caching Server, before the Check-in Procedure will release the ProjectWise Explorer session. Meaning, that the PW Explorer will first be release when the entire check-in to the Integration Server has ended.
When checking the document out again, the Cache on the Caching Server first has to be updated, as this does not happen when the document is checked back in, but first on the Checkout.
Could anyone comment on this?
If this is the case, why not just check-in to the caching server, and then let the Caching Server / Integration Server do the rest. The cache is up to date, and the user can work in the explorer again.
The reason to why I am asking is that we are having some Check-in performance issues (low bandwidth).
Essentially, it is a question of reliability. We cannot take any risks that a checkin operation may not complete (for example, due to network problems, disk out of space, etc). If we were to defer the checkin to the gateway cache, and the gateway cache were to suddenly go offline, there is a very real risk that your recent changes could be lost.
It is more reliable (and if you are using DFT, no less performant) to simply have the client write through to the caching server.
This issue has been noted in the past.
My understanding is that Bentley tested this and concluded that check-out is using DFT via the caching server and check-in skips the caching server cache and goes to the integration server and that this was supposed to be faster - mainly due to the time taken to generate the DTF check sums.
With large files and caching servers shanghai and interation servers in Europe we have a feeling the dft on check-in should be more dynamic - the time taken to generate the DFT for each hop must be less than a 100mb file transfer to Europe. Check-in large files from Shanghai is forcing people to wait a long time and there is the caching server update the next time some one uses it.
When you say that check-in of large files is causing a delay, what types of files are you working with ? Are you dealing with files that have many changes ? I would be very surprised to hear that the time required to calculate and exchange checksums between the client and the server exceeded the amount of time required to transfer a 100MB file from a remote office.
Thanks for the replies. I can see the issue about reliability.
We are using DTF, but we could try to disable it on the Caching, and check the speed.
Best Regards Christian
I would recommend using the provided DFT Benchmark tool for your testing. The tool also allows you to use your own files so that your results better reflects your situation.
It might not be clear that you should run the tool on the client machine (not on the server) as that is the client side location that you are most interested in for optimizing.