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 10 as well as older version like Uniface 9, 8, 7 and 6 - in large and small teams, with Linux 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:.
Disk storing the UD6 XML files (eg: NTFS vs FAT, Local vs. Network, SAN vs. NAS, SCSI vs IDE.
Anti-virus/Anti-Malware software settings.
Clustering.
is ULANA clustered with Components/Model.
is the 'new' UCRELSH setting in use (default is on)
is USTEMP and other 'binary' data stored in UD6 XML format or ISAM or a SQL database
Is 'auto-retrieve' disabled in IDF User Preferences screen?
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.
Anti-Virus/Anti-Malware Software Settings
The most common cause of poor performance is the configuration of anti-virus and anti-malware 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.
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
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:.
The source code is not going to change
UD6 will be the only process accessing the files.
The last write time of the file will be the same as the last UTIMESTAMP for all the entities within the file
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:
Never use these setting in a developers IDF ASN file, only use them for unattended batch build.
Note 2:
The recommendation is to use NEWDTD ENABLE but it will require you change the pattern in the 'joins' configuration file. If this is your first time upgrading to Uniface 10 or first time using UD6 - use NEWDTD ENABLE and change the 'joins' file. There is a comment in the 'joins' that explains what you need to do.
