VFP9 exe runs slow on WIN7 64-bit machines

35 - 40 concurrent sessions running a single VFP9 exe file on a virtual (Hyper v) windows server 2008 R2 SP1 12 GB RAM 64-bit server. Host machine is a Windows Server 2012 R2 standard 486 GB 64-bit Dell T420 machine.

1 user can log in and a specific application task will take 8-10 seconds. Additional users logging in extend the application time to 35-45 seconds. A new Win7 professional 64-bit 4 GB RAM machines takes 1:10 seconds to perform the same task with multiple users logged in. Older style 32-bit machines seem to run faster than the 64-bit machines, but overall time to perform tasks has gotten significantly worse with all machines.

Most users are running WIN7 professional (mix of 32 and 64 bit machines). What can I do to facilitate faster application response time on our network? I assume from reading other posts it's not a VFP issue as much as they way the network is allowing data to be accessed. Is that correct? If so, what's a user to do that depends on VFP9 ??

Thanks for your response.
HealthcomAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
pcelbaConnect With a Mentor Commented:
Just a few notes to above post:
1) The 3 hotfixes are declared as "Install at your own risk" by Microsoft but they are OK. More important is the fact FoxPro is not supported at all... (I don't count the last 2 months of the extended support period.)
2) FoxPro can use cca 1.5 GB of memory from 32 bit address space without patching.

W7/W2008 is slower than previous systems when you use shared file access. In addition to that you should apply some recommended settings:

1) Apply Alaska patch: http://www.alaska-software.com/fixes/smb2/overview.shtm#download
2) Switch SMB2 off on both server and workstations
3) Read something about opportunistic locking: http://fox.wikis.com/wc.dll?Wiki~OpportunisticLocking (and test oplocks disabling)
4) Move your app, its libraries, and temp files to local workstations. Server should host just shared data.
5) Disable IPv6 on your network - it slows the shared file access down

6) Think about your app redesign. Remote shared file access is deprecated in Microsoft.  App running in Remote desktop session is better solution because it can access data locally. VFP COM Server is also good solution but too much work...
0
 
gheistConnect With a Mentor Commented:
Visual Fox Pro is a 32bit application.
You need
1) Make sure redistributable components are VFP9 SP2 + 3 Patches (the only supportable version according to microsoft)
2) Patch image (EXE) to be IMAGE_FILE_LARGE_ADDRESS_AWARE and get more than 64MB RAM or so (it is a long story to tell, but basically it depends on some old MFC libraries, and wow64 locks it into very old compatibility mode)
0
 
gheistConnect With a Mentor Commented:
2. If it loads some control that uses visual C++ 6.0 runtime, odds are high it is landed in w95 bin and less memory (that is usually evidenced by compatibility assistant popping up when you close the program)

...

4) Instead of moving .exe to local drive, you can also try setting them read-only. That would make sure single lock is held per client (but then again imagine updating program ever)
0
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
pcelbaConnect With a Mentor Commented:
Yes, VFP 9 needs msvcr71.dll but it never displayed compatibility assistant on 64 bit machines to me.

If the app uses some (OCX) controls then these controls must be registered which itself is annoying complication on new computers.

Each VFP program should use a loader which checks for new updates as the first step and then starts the app itself. Of course, this is valid in the case of planned updates only. If you don't plan updates then the local drive ensures fast app start at least.
0
 
gheistConnect With a Mentor Commented:
We got rid of it approx 2 years ago, I can just report how it worked back then ;)

At the end we walked around each OCX with dependency walker to make sure it has no unwanted dependency on w95/NT4. etc etc.
0
 
HealthcomAuthor Commented:
Thanks for your quick reply's and suggestions. We're going to be attemping some of these fixes next week and I'll be able to report back. Any other last minutes thoughts...please feel free to send over.
0
 
HealthcomAuthor Commented:
We were able to turn off SMB2 and added a regedit entry to disable opportunitic locking. This significantly reduced task time from 46-55 seconds down to 8-10 seconds on WIN7 machines. Thanks for your helpful suggestions!
0
All Courses

From novice to tech pro — start learning today.