Understanding ProjectWise Delta File Transfer [DFT] Settings


  
 Applies To 
  
 Product(s):ProjectWise
 Version(s):All
 Environment: N/A
 Area: N/A
 Subarea: N/A
 Original Author:Bentley Technical Support Group
  

 

 

 

 

 

 

 

 

 

In a distributed ProjectWise network, Delta File Transfer (DFT) can provide a great savings in both network bandwidth and time when performing transfer operations such as copy-out / check-out / check-in. These savings are achieved by calculating the differences between the file the user has and what is on the Server, then sending only the changes between them back and forth. This document looks at the different settings related to ProjectWise DFT and when you may want to change them.

ProjectWise DFT settings

ProjectWise provides settings to control DFT at the Data Source, User, and Server level. By default DFT is enabled at all 3 levels.

At the Data Source level this is a checkbox on the settings tab of the Data Source properties.

At the user level it is controlled by a checkbox on the settings tab of the user’s properties under ‘Network’.

At the Server level it is controlled by the [DFT] section of the DMSKrnl.cfg, by default this section has no entry which implies it is enabled.

If you wanted to disable DFT for a specific Server but allow users to use DFT elsewhere in your environment you would set “enabled=false” in that Server’s DMSKrnl.cfg. You can also disable DFT on a specific Server for specific subnets by using an access control statement along with enable=true.

EG “enabled=true [ORDER(ALLOW,DENY),ALLOW(*.*.*.*),DENY(192.168.*.*)]”

**Please Note: A Server running the Temporary Caching role will still use DFT to download files from remote Storage Areas even when the user that requested the file has DFT disabled for their account or the subnet the user connect from has been denied from using DFT via an access control statement. In these cases the file delta is download and applied to the file on the Server running the Temporary Caching role and then the full file is sent to the Client.

DFT Related User Settings

There are 4 user settings that are important to consider when using DFT, “Leave Local Copy On Check In”, “Leave Local Copy On Free”, “Use Up To Date Local Copy On Check Out”, and “Use Up To Date Local Copy On Copy Out”

For DFT to deliver the most benefit to your users who don’t have a local Temporary Caching Server there needs to be some of the file in the users working directory to start with. Without “Leave Local Copy On Check In” or “Leave Local Copy On Free” set the files will be purged from the users working directory when that operation is performed. If the file is purged on check-in or free, the user will have to download the whole file next time they work with it. If the user is connecting via a Server running the Temporary Caching role this setting will have no effect on the file cached on the Server.

** Please Note: “Leave Local Copy On Check In” and “Leave Local Copy On Free” are not checked by default.

The second two settings, “Use Up To Date Local Copy On Check Out” and “Use Up To Date Local Copy On Copy Out”,  help out in that they can save the user from having to spend time calculating DFT checksums just to find out they already have a current version of the file. For most files this will be less than 1 sec of time but when checking out large datasets on slow WAN links this time can add up. These two checkboxes are ON by default.

Before changing these settings in your environment there are some important workflow considerations.  Depending on which settings you change files can be left in your working directory where they wouldn’t have by default and file in your working directory can be opened instead of any data being pulled from ProjectWise. This can lead to a situation where a user is not presented with the data they expected.

For example, say you set all 4 settings as in the example above, a user checks out a DGN, makes some changes, and then decides they want to abandon their work because they made a mistake. If they close MicroStation and free the file, the changes will still exist in the users working directory. If they then check the file out again they will be presented with the file they modified from there working directory, not the unmodified file in ProjectWise. This is because the local file is newer than what’s in ProjectWise so it’s believed to be up to date.

When would you want to disable DFT?

Whenever a user uploads or downloads a file through ProjectWise using DFT, both the Client and Server have to do some calculates on the file to figure out what parts are needed. In most LAN environments; depending on the size of a file, how much has changed in it, and Client/Server performance, the amount of time it takes to do the calculations and then exchange the changes can take slightly longer than sending the full file across the network. Normally the difference in time is only milliseconds to a few seconds but it will depend on your work set and network. In WAN environments the time to do the calculations will almost always be less than sending the full file but again it will depend on your work set and network.

Below are some common situations where you may want to consider turning off DFT for some or all of your users.

When considering disabling DFT for a Server you must take into account all roles the Server has and how users connect to the Server. If you have a Server at a remote site running the Temporary Caching role and the Storage Area role you might be tempted to use an access control statement to disable DFT for local users to improve file transfer. The hidden issue with this is the Temporary Caching role will not cache the file check-in operation to a remote Storage Area so while file download may improve, file check-in to the remote Storage Area will suffer.

Timing Example:  For a Client connecting to a Temporary Caching Server to access files across a WAN link with 1.5mb bandwidth ~150ms latency.

(DMSKrnl.cfg from the Server running the Temporary Caching role with DFT enabled)

(DMSKrnl.cfg from the Server running the Temporary Caching role with DFT access control to disable DFT for local users)

In the above example the check-out of a 20mb file improved by 1.2sec by using access control to disable DFT for local users.  However the check-in of the file took 105.9sec longer than if we left DFT alone. The net effect is it doesn’t make sense for us to disable DFT unless users will never need to check-in a file when connected to this Server running the Temporary Caching role.

How to test DFT performance

Testing DFT with ProjectWise Explorer is possible but it is a tedious, time consuming, and error prone process. To address this testing need Bentley delivers a DFT Benchmark tool as part of the ProjectWise Administrator install. The tool is installed in the ‘Bentley\ProjectWise\Bin’ folder under the name dftmwiz.exe.

** Please Note: On 64-bit systems the benchmark tool will be in the bin folder under
‘Program Files (x86)’

The benchmark tool provides a straight forward wizard that allows you to test DFT performance with ether three auto-generated files of 100k, 2mb, and 20mb, or provide your own file in two different revision states. The output of the wizard is pictured in the ‘Timing Example’ above and provides the time to copy-out and check-in a change to the file both with and without DFT enabled.

For more information on using the tool please consult the Implementation Guide and the Help in ProjectWise Administrator.

It is important when evaluating DFT performance to run the test several time, at different times of the day, as network load and latency often fluctuate during the course of the day which can have a large impact on performance.

ProjectWise DFT and Riverbed Steelhead

If you already have Riverbed Steelhead deployed there is still benefit in leveraging ProjectWise DFT to reduce the amount of data being sent between the Client and ProjectWise Servers. For more information please refer to this joint paper from Bentley and Riverbed. http://ftp2.bentley.com/dist/collateral/docs/projectwise/WP_Riverbed_ProjectWise.pdf