Improve Speed across Kilostream Link?

[FoxAl]

I have standalone Foxpro 2.6a for DOS executable running on 2 sites connected by Kilostream link. All PC's (W2000) are mapped to server where executable resides. On the site where the application resides, accessing and logging on to the application is virtually instantaneous, however, on the remote site, the load time is in excess of 1 minute 30 seconds.

When users accessed the application from a remote site using W95, 98 the log in time would be approx 30 seconds and this was attributed to the slow speed of the kilostream link. However, a further 1 minute delay simply because the PC's are now W2000 seems excessive.

I have tried to optimise the remote site environment by having local configuration files, emuulating W95, 98 mode through Icon properties and maximising Extended and Expanded memory, but the best 'fix' I can get is still taking approx 1 minute to load.

Does anyone have a winning solution for solving the delay or suggestions on what to try as may be causing the excessive delay.

PS: Once loaded the response time on the remote site for doing transactions is slower but only for a delay of 1 second or so. It is simply the load up which causes users heartache.

Thanks!

 

[cricket]

Place a copy of the executable on each machine at the remote location
Set temporary files to run on local drive
tmpfile=c:\temp in config.fp

 

[FoxAl]

Cricket,

I need all users who are sharing files within the application to be able to see other users changes as soon as they are made. If I set up an executable on each users PC at the remote site then we would have multiple copies of the data with everyone only seeing their own changes.

It is designed as multi user input/output application.

 

[DSummZZZ]

If you can map the drive where the executable is, you can specify in the app running locally where it can find its data. Somewhere in the app itself, add the line:
SET PATH TO d:\datapath

-or-
Create a CONFIG.FP file in the executable's with the following line in it:
PATH=d:\datapath

Where d:\datapath is the mapped drive where the data files reside.

Then, make sure that if you have anti-virus software installed, set it to not scan .dbf's, .cdx's, .fpt's and other FoxPro files which don't need scanning. That should help increase response time.


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[FoxAl]

DSumm222,

Thanks. I already have the exe set up with a set path command as you suggest, not in exactly the way you suggest but similar. I create a system.dbf in the root dir of where the exe lives on the server with a field called app_path. The users can edit this field to point to where their data lives (usually server) but also allow them to point to different datasets if required. This value is then passed through string when opening files.

The snag is that we have to wait a minute 30 seconds before the exe starts before we can access the setpath command within it.

The problem I have with the 2nd approach is that all users run the same executable on the server drive. Both this and the resource file are read-only such that only 1 copy is ever in user for all (perhaps not best but has worked for years).

 

[DSummZZZ]

So do you have anti-virus software running on those workstations?
Also, do you have IPX/SPX protocol on them?


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[FoxAl]

DSumm222,

The anti-virus software is running on these PC's. It is outwith our control to check or disable this or prove that it could be a possible cause and the politics are such that we support software for the app but not other apps, hardware, links or networks.

This is not so much passing the buck but more observing the rules - if we change something which causes a virus on their system - who do you think would be blamed?. If I help a blind lady cross the road and she gets knocked down - who is to blame?. I appreciate the goodwill of intent is there but politically we cannot investigate it.

All I can do (or not do) is prove that we cannot optimise the speed further through Foxpro. If the hard facts dictate that W2000 takes 90 seconds to load and W95/98 takes 30 then I am comfortable in relaying these facts to them as a forfeit for using W2k but only if I can exhaust the software possibilities first.

Sorry to be rather pedantic on the above as I do appreciate and value your help, but it is simply not an option to proceed further with your query on the anti-virus approach.

Any other input is still much appreciated.

Thanks!

 

[DSummZZZ]

I understand your position fully. I am one of the folks here that forbids people from touching AV myself. But, if you have the same AV software and settings on the NT box as you did on the 98 box, that may not be an issue. Keep in mind that when an app is instantiated remotely, it first must 'download' the app, all necessary runtimes, scan them as a download, then possibly scan them at runtime. Then, upon opening the data files, it must then scan the data files as well as index files, memo files, ....
Another issue may be that NT doesn't always 'connect' to the drive mapping until it actually has a request to access it.
You must also verify network clients, protocols and settings are the same on both boxes.


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm