FoxPro 2.5 (DOS) VERY SLOW on Network!

[rarivera53]

I have a FoxPro 2.5 (DOS) run-time app that runs fine in a peer-to-peer environment or as a stand-alone, but once I put it on a network, it becomes painfully slow!

I have an older version of the same app, which runs fast on the network, but I no longer havethe source code for that version.

Is there a file that needs "tweaking"? Is there something that I can do to speed things up without having to go through all of the programs?

Thanks immensely for any help.

 

[rgbean]

There is very little you can do programatically. Much depends on your server (type and configuration), your network (type, topology and clients) and of course the actual hardware (NICs, cabling, etc.)

Rick

 

[rarivera53]

Why does the previous version run so much faster?

 

[realm174]

Just a shot in the dark, but could it have something to do with the file/record locking? If only one user is using the program on the network, is it still slow?

 

[rgbean]

Previous to FP 2.5, or on a peer-to-peer network?

For a Peer-to-Peer network, the client software is much different, you may even be running a different protocol. (NETBIOS vs. TCP/IP or IPX) Are you now running through a switch, router, hub that you weren't before? Are there many more users than before? Have you run a network monitor to see if you are experiencing a lot of retries?

Where do your CONFIG.FP files place the tempfiles?

Rick

 

[rarivera53]

It may have been FoxPro 2.0, although I'm not sure.

What I DO know is that in three different agencies I had this issue, and in each case the software was loaded on a network (1 using Novell, 2 using Windows NT).

When the software is configured as peer-to-peer app, the issue goes away.

It doesn't seem to make a difference how many users are on at a time, but I can't say for sure.

 

[rgbean]

Other than making sure the temp files are local, it's good to have the FP runtimes local on each work station too. Last, if you are running the code from the server, consider using a "launch" program to store the application code (.EXE) locally also - this can greatly reduce network traffic.

Rick

P.S. Wait until you try running a VFP 7.0 app on a Win2000 server - you'll find somethings are even slower (assuming the same hardware), because of the increased system / server features and requirements.

 

[rarivera53]

I AM storing the .TMP files locally, on each workstation; however, I am running the .APP run-time file from the server. I don't run a .EXE file.

Should I run the .APP locally?

In one instance, we DID have the network monitored. The result indicated a massive amount of "polling" between the server and the workstation.

What puzzles me is that I can take the same hardware/network environment, simply swap the old app with the new app, and get such a dramatic difference in performance!

The files are essentially the same size; I DID make significant cosmetic changes to screens, but nothing that should make such a difference in performance.

 

[rgbean]

One thing we haven't explored, is whether you are running this on DOS only workstations, or under Windows? One big change between 2.0 and 2.5/2.6 was the memory manager / model used. Because 2.0 was a Fox Software product, it was compiled with a different (Watcom) compiler and used a different linker than the Microsoft versions. You can't run the Extended memory version of these under Windows, and you've got to be careful in configuring the Expanded (EMS) memory or the application will be stuck running in less than 640KB memory - this could explain running slower.

Does the application have a "status" screen that display the values for sys(1001), sys(12), and sys(23)? It'd be especially useful if it was in both versions. Do you use a MEMLIMIT in your CONFIG.FP file? If yes, what values do use? If not, why not? The defaults aren't really good enough.

Rick

 

[rarivera53]

The app is running on Windows 95, Windows 98, Windows 98 SE and Windows ME workstations and Windows NT servers.

The items that you mention are, in fact, included in the app. There are reported as follows:

SYS(1001)
FAST Version: 91,078,656
SLOW Version: 91,070,464

SYS(12):
FAST Version; 431,104
SLOW Version: 431,104

SYS(23):
FAST Version: 0
SLOW Version: 0

We DO NOT user MEMLIMIT in CONFIG.FP. What should it be?

Thanks.

 

[rgbean]

I've found that
MEMLIMIT = 60, 2048, 16384
works good. I believe that 16MB is all that FPD can really use. This would need to be pushed back on systems with less than 32MB of real memory, or if you have any other large apps running - including another FPD app.

I also must change something I wrote earlier, it's actually EMS you can't use, I've got Extended (XMS) and DPMI meory set to Auto in the .LNK (or .PIF) file for my FPD apps. (Sorry, sometimes what you remember isn't exactly right - that's why I checked this time. <g>)

Rick

 

[zimbaliza]

hmm, I think FPD can handle more than 16 megs,
FPW 2.6 had the problem with 16 megs and above, not FPD.
(well I run FPD under DOS! nothing else), can run it under
NT, if I am to lazy to boot to dos....

Only thing I can think of it... maybe the app isn't in
enchanced mode

i.e.

foxr yourapp.app +X

should speed it up

Zim

 

[rarivera53]

No, that's not it, either.

I run the shortcut as &quot;foxr.exe +x main.app&quot;