I’m having the same issue after a big server migration last week. I’m using VMware, and the setup is as follows:
1. The VMWare host hardware is an HP G6. It has 24 GB of RAM, 2 quad-core Xeons , about 1.4 TB of local storage in a SAS RAID 5 (15000 RPM hot-swap SAS drives), and dual GB NICs.
2. One VM is a File server: Windows 2008 R2 64-bit, where the shares are. It has been set up with 2 processors and 4GB RAM. This is where the fox tables are located.
3. One VM is a terminal server: Windows 2008 R2 64-bit, set up with 4 processors and 16 GB RAM. Drive shares are mapped in the user profiles and the application uses tables on the network share.
Application performance under this setup is slow. The two VM’s are on the same physical host. I have been told the virtual network between them, though nominally a 1GBit network, is not actually constrained to that limit between two VM’s. I tested the throughput between VMs by copying large files. It takes about 20 seconds to move a 500MB file between the two VMs. Most of my tables are not that size, though some few are.
Troubleshooting steps I’ve tried:
1. Doubling the memory allocation on the terminal server – no effect.
2. Refactored a VFP report in the app that queries from two large tables. I created a temporary database on c: drive, copied structure on both tables to temp tables in that database and appended records from the production tables to the temps. Then had all queries run against the temp tables. This runs about ten times faster, after the initial overhead of creating and copying data to the temps. Bear in mind that c: drive and the network shares are actually on the same physical host.
3. Test runs on a long-running update process:
a. VM to VM - Slow.
b. Physical box to VM file server – Slow
c. Physical box with data on local drive – Fast
d. VM with data moved to temp tables on ‘local’ drive – Fast
e. In development environment on a different network: Physical box over Physical LAN to a Physical file server – Fast. (This test is not under the same user load, so may not be very informative)