Hi, I have a puzzling issue with the performance of FoxPro after trying to use it on virtual machines in Azure. This issue occurs on a Remote Desktop VM in Azure and also on our test VM.
Essentially, when there is only one person using FoxPro the performance is fine, but if another person uses it and opens a table it will take minutes to open. This happens when RDPing to the server and then running the app, so it's being run directly on the server itself, but the same thing also happens when the app is run as a published app in Remote Desktop (which is ultimately how we want it to be used).
There shouldn't be any issue with network performance as both the app and the database is on the same drive on the server in Azure. The disks are also premium SKU. Enabling read/write caching on the disks makes no difference.
We even have a test server which has a copy of app and database on a drive on the server and this works fine with the server in the office. But after the server was migrated ('lift and shift') to Azure (the Azure VM specs matched those of the VM in the office), it too has the same performance issue when a 2nd person tries to use FoxPro and opens a table.
I'm not a FoxPro developer, so my knowledge of FoxPro is rather limited, but I've been assured by the developer I am liaising with that things like table buffering, locking, non-exclusive file access and rushmore optimisation have all been checked. As I say, it's working fine on the server in the office, but just has this issue when running on VMs in Azure! AV is Defender and the database files are excluded from AV scanning.
Apologies if this is all quite vague, happy to fill in any more details that you might require. If anyone could assist in figuring out what's causing this performance issue I will be extremely grateful!
Best Regards,
Essentially, when there is only one person using FoxPro the performance is fine, but if another person uses it and opens a table it will take minutes to open. This happens when RDPing to the server and then running the app, so it's being run directly on the server itself, but the same thing also happens when the app is run as a published app in Remote Desktop (which is ultimately how we want it to be used).
There shouldn't be any issue with network performance as both the app and the database is on the same drive on the server in Azure. The disks are also premium SKU. Enabling read/write caching on the disks makes no difference.
We even have a test server which has a copy of app and database on a drive on the server and this works fine with the server in the office. But after the server was migrated ('lift and shift') to Azure (the Azure VM specs matched those of the VM in the office), it too has the same performance issue when a 2nd person tries to use FoxPro and opens a table.
I'm not a FoxPro developer, so my knowledge of FoxPro is rather limited, but I've been assured by the developer I am liaising with that things like table buffering, locking, non-exclusive file access and rushmore optimisation have all been checked. As I say, it's working fine on the server in the office, but just has this issue when running on VMs in Azure! AV is Defender and the database files are excluded from AV scanning.
Apologies if this is all quite vague, happy to fill in any more details that you might require. If anyone could assist in figuring out what's causing this performance issue I will be extremely grateful!
Best Regards,