-    PERFORMANCE: WHAT MAKES UD6 SLOW OR FAST    

Optimising Performance of Uniface with UD6

UD6/CMtool driver is a designed for storing your Uniface source repository and using the IDF quickly and efficiently.

We have many customers using UD6 with Uniface 6, 7, 8 and Uniface 9 - in large and small teams, with Unix servers and also with Windows Desktops, using a variety of change control methodologies and tools - and performance is great at most installations. If you have a performance problem - contact us because these problems can almost always be solved after some diagnostic processes.

For many people trying UD6 for the first time the performance is adequate. Regardless of if the performance is OK or clearly needs improving - the performance can probably be improved by checking several settings and talking to our technical support team. A single page in a help file is not going to resolve every issue - please do contact support@march-hare.com if you have persistent performance issues so our team can help you.

What affects the performance

UD6 performance is affected by many things:.

Clustering

This help file contains a page on Clustering: What is stored where in UD6. The clustering options chosen 'by default' are a balance between 'usability' and 'performance', ie: the default is not the best performing. To discuss you clustering requirements and the effect on performance please talk to our support team via support@march-hare.com

Anti-Virus Software Settings

The most common cause of poor performance is the configuration of anti-virus software on windows. The XML files can never contain a virus - they are not executable files, therefore it is never sensible to scan them for viruses. UD6 can read thousands of XML files every second - but this rate can drop to 100's or even fewer when some anti-virus systems attempt to scan every file every time it is accessed.

Disk storing UD6 XML files

For the best performance store your UD6 XML files on a locally attached SCSI disk with a battery backed write cache. The worst performance will be obtained by using a 'NAS' or a 'Network Share'.

Auto Retrieve

The IDF user preferences can be used to turn off 'auto retrieve' on browse screens like the 'open component' form. If your repository contains several thousand components then you are unlikely to scroll through the list to find and open the one you want. Creating and populating that list takes UD6 time that is then wasted if you just 'clear' that form. It is best to turn off 'Auto Retrieve' and then the 'open component' screen will appear instantly.

Performance of Batch Build

Batch build is using either 'make' with a Makefile, Maven or simply using idf/all or idf/frm

When batch building in a separate workspace/sandbox there are some key changes:.

File Access

If a file is read-only then when UD6 writes changes it should generate a 'record locked' type message. However during compilation we know the file will not change (except for UTIMESTAMP and UCOMPSTAMP which UD6 3.1/UD6 2.1.05.1209 'recommended settings' does not write anyway).

All of file access checking is simply unnecessary in a build environment - so we recommend you use a separate ASN file for build environment and you 'turn off' this check.

The recommended settings are: 

USYS$UD6_PARAMS=nodeny

Never use this setting in a developers IDF ASN file, since the developer will not be able to 'see' if a change has been unsuccssful due to a read-only or locked file.

Exclusive Write / Lock Files

In UD6 3.1 (recommended settings for UD6 2.1.05.1209) UD6 locks the XML files when writing changes. This is unnecessary in a build environment - so we recommend you use a separate ASN file for build environment and you 'turn off' this feature.

In practice this should have very little effect, since the files are not updated anyway, there is no need for UD6 to lock them.

The recommended settings are: 

USYS$UD6_PARAMS=exclusivewr disable

Never use this setting in a developers IDF ASN file, since the developer will see many 'record reloaded' errors.

Build caching

In UD6 3.1 (recommended settings for UD6 2.1.05.1209) UD6 does not write timestamps to the UD6 XML file. UD6 maintains a cache of UTIMESTAMPs for each record within a UD6 XML file. For example: in a Form Component this would include the timestamps of the Form Component itself (component level triggers), Component variables, Entitle level triggers, Field Level Triggers etc. If you change a field level trigger but not the component, then the IDF will perform a 'reload' if the correct UTIMESTAMPs are not maintained.

All of this is simply unnecessary in a build environment - so we recommend you use a separate ASN file for build environment and you 'turn off' this caching.

The recommended settings are: 

USYS$UD6_PARAMS=forcedate file

Never use this setting in a developers IDF ASN file, since the developer will see many 'record reloaded' errors, instead this setting is the recommended default: 

USYS$UD6_PARAMS=forcedate cache file interval 0

Combined settings

The recommended settings are: 

USYS$UD6_PARAMS=nodeny, exclusivewr disable, forcedate file

Therefore for UD6 2.1.05.1209 the recommended default for automated build is: 

USYS$UD6_PARAMS=nodeny, exclusivewr disable, newglobals v2, fix6870, ud6ide, xmlschema w3c-2001 ie11, xsl w3c ie11, config E:\Uniface_10-3-02\common\bin, supresszero v3, timeforce 4, boolforce 2, autodef, fix5635, compiledate cache file, numforce disable, bug6759 all threshold 80 memstep 4096, asnfile E:\Uniface_10-3-02\uniface\adm\ide.asn, notimestamp all, nocompstamp enable, forcedate file, ucrelsh 200, refresh 240, newrels disable, mmf files 2048, makefiles reverse group nocase enable wait filename .\sources\makefile.mak, option pack E:\Uniface_10-3-02\common\bin\mhgfp140.dll

Never use these setting in a developers IDF ASN file, only use them for unattended batch build.

Read more about Uniface Version Control

$Revision: 1.5 $ $Date: 2020/09/24 11:49:59 $[go to top]