Foxpro App performing poorly across network 1

[Denverdoug]

We've got a client with a Foxpro App that imports and manipulates a huge text file (in this case ~180Mb) from a network drive. Under normal circumstances, our program does the trick in 3-5 hours on a P3 with over 128Mb RAM. In her case, it is taking well over 10 hours.

The server is NT Enterprise on a clustered RAID system. She's only running IP and the client is Win 98. One interesting note - the PC is on a switch. She switched from a 10Mb/S to a 100Mb/S connection and that reduced the time from 17 to 10 hours.

What could drive the performance down so much in this case? Any suggestions?

 

[foxdev]

It sounds like the file resides on a server, but the actual processing is done by a client PC. If that is true, then the speed and RAM of the client is very important. The nature of the server, its drives, and the network affect the file reads, but doesn't directly affect how quickly the client processes the data once it is pulled across the network.

Do you have the specs on the client PC?

Robert Bradley

http://www.foxdev.com/

 

[Denverdoug]

The client PC is P3 866Mhz with 128Mb of RAM. We do similar processing for other clients locally with P3 667 & 256 Mb of RAM and our performance is much better across our network.

The client has already told us that she's run it from a local PC in half the time so my assumption is it's a problem with network traffic. But - if there's a way that the VFP app could be modified to work around that, it may be worth a shot. Unless of course, it means redeveloping the entire application.

And you are correct, the data lies on the server and the processing is done locally.

 

[dgrewe]

I have been critizied in the past for this and told I was nuts and the forum ran me into the ground stating my theory was flawed but,
I have discovered that the best solution to working with large files is to write the program where all the work on the local computers hard drive and then copy the final product to the network. I have even found that on computer with 2 independent local hard drives, work is even faster when you can write the program to read from one drive and output to a the second drive. NOTE I said independent drives not a partitioned drive.

With that said let the critics start in again.

David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[BlindPete]

That is exactly what I do in certain circumstances. Most recently on a WAN where the process was very intensive.

Pete
blindpete@mail.com

What your mother told you is true! You will go blind! (from moonshine anyway)

 

[Denverdoug]

Unfortunately, pulling it over is not an option for most of our clients. Some of these tables are 3-4Million records, 200 bytes each.

 

[dgrewe]

Then the fastest speed you will ever get is tied to several factors.
1. The speed of the connection to the network. (You said 100mb)
2. Network Traffic (You said the person was on a Switch).
3. The Speed of the Server Hard Disk.
4. The Speed of the Server Processor.
5. The Amount of memory in the Server.
6. The Number and Size of requests from other users on the network.
In short, The network can only move information as fast as the slowest part in the link.
You need to face the client with this statement. A 30gig Hard Drive only cost $150 so what is more cost effective, A new hard drive for a copule of computers or the salary of an employee to baby sit a computer to 10 hours * number of time run a year?

David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[schavlytko]

This terrible ! 10 hour !
I am doing next:
1) copy text file on the local computer
2) convert text file in the dbf file if lenght onr string less then 256 bytes and work with dbf file.
If lenght more then 256 bytes - I would change outgoing file for more faster structure (fixing lenght filds except commas delimeters.

It all sounds so interesting.