XP Performance 2

[xiong]

For those of you researching the problem of FoxPro Databases and performance in XP environments, this is just a bit more "ammunition", and not a solution. Hopefully it will aid in tracking down a root-cause solution

Though, I've not been able to uncover any specific information from Microsoft, it's obvious some major changes were made to the VDM. In working with a COBOL program, a FPD application, and an FPW application, there are a number of things we've documented, but found no workarounds for.

I have a number of clients running in various network configurations with XP. Those with XP are noticing considerable lag-times when accessing the FPW application. What follows is a list of the knowns:

-Servers can be either NT4 or 2K
-Access from 9x and 2000 workstations is much faster, and even more so in a "pure" enviornment
-Network size is not a factor, as some have 2 workstations, while others have as many as 20
-Clients running NETBEUI see no improvement
-CONFIG.FPW file settings have been tweaked to match some of the tips found here, but again, made no difference
-Client specs range from 450MHz machines with 64 MB memory to 1.6GHz with 1 GB memory. Again, no differences
-FPW applcation is running with the 2.6a patch.
-Database size varies greatly and does not seem to be a contributing factor
-Most configurations do not have any internet access, much less high-speed access, and most do not have/need a firewall
-benchmarks regarding file transfers outside the application spec out ok
-neither workstation or servers exhibit any peaks in memory or processor utilization
-network traffic is still being monitored
-number of users concurrerntly connected does not seem matter
-VDMxxxxx.TMP files caused major problems in Win2K Pro environments, clogging data directories, but have not been detected in the XP scenarios

Anyone with more information or more known scenarios, please post. This is an issue that could cause some major problems for future development.

Thanks


~Let Him Who Desires Peace, Prepare for War. (Flavius Vegetius Renatus)

 

[Nigel Gomm]

Are there specific points in your application where performance is noticably worse for the XP workstations?

when first using XP (win2k as well if memory serves) i was experiencing a significant delay when terminating a READ.
Application would run OK otherwise but switching between screens could take up to 5 seconds.

It was resolved by SET AUTOSAVE OFF.


Nigel

 

[xiong]

Our usual benchmarks on other systems run 2-4 seconds between screens. We're now in the 30-60 second range for XP workstations. Seems as though all functions are equally as bad at this point, but we're still in discovery mode.

 

[xiong]

Looks like we're getting closer to the culprit. Seems Microsoft has finally published something to this effect. I've noticed that the performance issue they refer to is especially true for 16-bit applications over a LAN.

When we get SP2 and have had a chance to install and test it, I will post our results.

Note the following Q article for more information:

http://support.Microsoft.com/default.aspx?scid=kb;EN-US;Q815411

 

[zucaro]

I have been following your thread with interest
are any of your problems similar to the following

I posted a thread stating
"
the problem is intermitent..usually first up but settles down.
the error response is "not a table dbf"
the table is ok though..I can access it at the same time
from another machine(win98)
I thought I had it sorted by turning prefetch off?
this seemed to improve it but has not eliminated it
It seems to me a buffer broblem with XP and
16bit applications (what is XP doing)
any ideas
"

Is SP2 available yet?

 

[xiong]

There is a SP1a available, but it does not address the issue of performance. There's no word on a timeline for SP2 yet.

The problem you state sounds familiar. In one of our cases it turned out that the latency of XP was causing indicies to not get created when they should and was crashing our app. The system would create temporary file in a user folder as the index was in process of creation, but would never be completed by the final copy back to the network location. A few hundered of these files would eventually crash the program. The other problem was during large processes, with XP running in addition to other workstations using 98 or 2000, a number of DBFs would become corrupted as the files were not written to in a timely fashion.

At this point the only sure fix is to remove XP from the equation.

I hope this helps.

 

[zucaro]

thanks for your help eslersa
removing XP is a dificult conclusion to come to!
we have had a policy of trying to migrate into new
OSs for replacement machines on our network.
lack of support from MS makes FPW2.5/6 more fun

 

[tatonka]

Eslersa, are the lag-times specific to FoxPro?
I had similar problems accessing/opening files across my network, regardless of application, and resolved it with a registry fix (FoxPro is back up to speed).
I am not sure if this is the most suitable place to post it but…let me know.

 

[xiong]

Honestly, that's hard to answer. The bulk of our clients with this problem only use our FoxPro app over the network. From what I've heard otherwise, it should affect 16-bit applications more so than 32-bit. A few of my case studies using other applications, none are 16-bit other than our app.

Another fix was to run a few of our clients over Terminal Server. The few with Windows 2000 server found this a relatively easy fix, and showed significant performance increases. Even on workstations running good already, going to a server-side solution makes for a more stable enviornment.