xBase++ client performance degrades significantly as database files are opened locally on the server
I have found a strange performance issue with xBase++.
Essentially, client performance is very good until database files in the same database are opened locally on the server (see graph.)
Details are below.
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.txt
Essentially, client performance is very good until database files in the same database are opened locally on the server (see graph.)
Details are below.
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.txt
ASKER
Thanks very much for the input. Could you elaborate on:
#3 - how is that setup? Running the clients in RDS sessions on the server itself?
#4 - How do all paths use native drive letters?
What I will try:
1. Using a different database driver in the xBase++ app to access the data via SAPs Advantage Database Server instead of directly through a drive mapped to a folder share.
2. Testing of #3 and #4 based on your additional input.
3. Look and see if xBase++ supports COM servers and what the impact of that method has on the existing app.
Thanks again,
Tim
#3 - how is that setup? Running the clients in RDS sessions on the server itself?
#4 - How do all paths use native drive letters?
What I will try:
1. Using a different database driver in the xBase++ app to access the data via SAPs Advantage Database Server instead of directly through a drive mapped to a folder share.
2. Testing of #3 and #4 based on your additional input.
3. Look and see if xBase++ supports COM servers and what the impact of that method has on the existing app.
Thanks again,
Tim
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks again. I'll post my results after I have finished just for completeness. I'll let you know if I have any more questions.
ASKER
Solution gives me several avenues to proceed as well as nicely explaining the performance scenarios.
ASKER
In follow-up, after working the Alaska xBase++ support, this is the expected behavior and there is not a solution.
To solve this problem I migrated from direct file access via a share to using Advantage Database Server which provides a client server solution.
Performance was very good for 100+ sessions on multiple workstations.
One throttling factor was CPU load which I solved by going to a 2 CPU server with 10 cores on each CPU. Increasing the number of cores proved more beneficial than increasing CPU speed.
To solve this problem I migrated from direct file access via a share to using Advantage Database Server which provides a client server solution.
Performance was very good for 100+ sessions on multiple workstations.
One throttling factor was CPU load which I solved by going to a 2 CPU server with 10 cores on each CPU. Increasing the number of cores proved more beneficial than increasing CPU speed.
Thanks for the info!
To know Sybase ADT works well for you is good to know.
To know Sybase ADT works well for you is good to know.
Yes, the shared files access is deprecated and less and less supported feature. We can do two things:
1) Ask the OS vendor "How to optimize the server setup for shared files access?" (You could also ask Alaska whether they asked already...)
2) Start using Client-Server architecture which makes more money to software vendors so its support is at much higher level...
Maybe you could also post a graph without the 2008-2008 line to demonstrate the speed without this break.
We are using similar applications written in Visual FoxPro. My observations are:
1) Everything is much slower than on XP-2003
2) To have data in shared folder on the server is not recommended in newer operating systems
3) Running the application in Windows Terminal server mode (RDS) which has data locally on the server is still very fast
4) To map the server data folder in Terminal server mode under new drive letter degrades the speed 5 times... Using UNC paths also slows the speed down... We don't know why. So all paths use native drive letters.
5) The most reliable VFP application for WANs is VFP running as a multithreaded COM server and clients then can use any connection available. BTW, does Xbase++ support COM servers?