xBase++ client performance degration as database files are opened locally on the server

[tfcallahan1]

I have a project converting a large clipper 5.2 system to xBase++.
The system uses DBF/FPT/CDX files with the FOXCDX dbe.
In operational testing I found a strange performance issue which is described below.
Perhaps it is something in my dbe setup? I’ve included my dbesys.prg. It’s setup for clipper compatibility but that is not a requirement for the new system.
Thanks,
Tim


Test Setup
--------------
• Three client platforms and two server platforms, all under controlled conditions.
• Clients: Win7 10/100, Win7 gb, Win Server 2008 R2 via XenApp
• Servers: Win Server 2012 R2, Win Server 2008 R2 (VMware virtual machine)
• xBase++: 2.00.785
• Dbe: FOXCDX (see dbesys.prg example)
• Client test function: representative function that creates a DBF/CDX file on the client C: drive from data assembled from multiple open data files residing on the server.

Test Procedure
------------------
1. Reboot the server
2. On a client map a drive to the server database share
3. Run the app from the client c: drive, starting it in the mapped server folder – performance is good for multiple simultaneous clients
4. Run an app locally on the server and open files in the same database folder as the client
5. As the number of files opened locally on the server increases the client performance degrades significantly for all clients, even new instances on different machines (see graph)
6. Close the locally opened files on the server
7. Client performance remains degraded

Notes
-------
• The performance is poor for all subsequent clients once a database folder has files opened locally on the server
• The performance degradation is limited to the specific folder containing the database. That is, if you run the tests on a database in a different server folder the performance is good until files begin to be opened on the server in the this new folder.
• A server reboot is required to fully clear the database folder “contamination”
• The results in the graph are representative, many more combinations were tried with the same results
• The results are the same for all client and server combinations

DBESYS.PRG
----------
#include "AppEvent.ch"
#include "dbfdbe.ch"
#include "foxdbe.ch"
#include "cdxdbe.ch"
#include "dmlb.ch"

PROCEDURE dbeSys() // Set the database driver

set(_SET_COLLATION, -1) // -1 = ASCII from xbase 2.0 collat.ch; definition from SET COLLATION TO in std.ch uses ASCII which appears to be the clipper default

// Load engines and build
DbeLoad( "FOXDBE", .T.)
DbeLoad( "CDXDBE",.T.)
DbeBuild( "FOXCDX", "FOXDBE", "CDXDBE" )

// Set up for Fox 2.x compatabilty
// The Clipper apps will use cmxfox52.obj to force Fox 2.x locking compatability
DbeInfo(COMPONENT_DATA, FOXDBE_CREATE_2X, .T. )
DbeInfo(COMPONENT_DATA, FOXDBE_LOCKMODE, FOXDBE_LOCKMODE_VISUAL) // Respects clipper locks (f and r) when clipper linked with CMXFOX52.obj
//DbeInfo(COMPONENT_DATA, FOXDBE_LOCKMODE, FOXDBE_LOCKMODE_2X) // Respects clipper file locks, not rlocks
//DbeInfo(COMPONENT_DATA, FOXDBE_LOCKMODE, FOXDBE_LOCKMODE_AUTO) // Not tested
//DbeInfo(COMPONENT_DATA, FOXDBE_LOCKMODE, FOXDBE_LOCKMODE_CLIPPER) // Respects all locks but need to remove cmxfox52.obj from link script

// Set default DBE to DBFCDX
DbeSetDefault( "FOXCDX" )

// Increase the index file lock retry count
// index files are locked exclusively whenever they are WRITTEN and *READ*
// increasing this timeout helps avoid failure of this lock under increasing loads
// this is a possibility
DbeInfo( COMPONENT_DATA, CDXDBE_LOCKRETRY, 1000000)
// Configure CDXDBE for COMIX compatability == FoxPro 2.x CDX's
DbeInfo( COMPONENT_ORDER, CDXDBE_MODE, CDXDBE_COMIX )

RETURN