NETWORK BOTTLENECK USING FOXPRO & VISUAL FOX PRO APPS

[vinylbilt]

We have a network running Windows 2003 Server with ActiveX Directory on a 1GIG (Unmanaged Switches) Network with 25 WS (using MS VISTA, XP and 2K) . We’re running FoxPro 2.6 Tables with DOS code page and Visual FoxPro 7.0 Applications, as well as DOS FOX 2.6 applications. We are experiencing high amounts of data traffic and spikes (300 GIG over netbios and MS-DS) over the course of eight hours. We have a server sniffer appliance and have noticed that one line of order entry in our VFP7.0 application, is transferring 68 MB of data across the network, even though the most it should be transferring is 50 KB. This large amount of data transfer is bottlenecking our network bringing response time to a slow crawl. Does anyone have an idea as to why this much data is being transferred or how me might optimize or fix it? A reward for the best suggestion will be given.

 

[JRB-Bldr]

"Does anyone have an idea as to why this much data is being transferred"

Without knowing the specific code being executed we have no way of knowing how efficiently it is written nor how it is accomplishing its task.

We don't even know what the code is supposed to do with the "one line of order entry" data.

Can you go into the VFP development environment and find which specific line(s) of code are creating this 'spike'?

If so then the methodology used and the results can be better reviewed.

Good Luck
JRB-Bldr

 

[vinylbilt]

We assume the code that generates this traffic is APPEND BLANK followed by GATHER MEMVAR. This spike is not consistent. One line generates traffic of 68 MB and a subsequent line only generates 20 KB of traffic, although the lines are identical.

 

[cricket]

Dont expect to make sensible line by line traffic comparisons. Data is buffered in network cards, workstation buffers etc

Where are your temporary files stored? Use the workstation as a location to minimise traffic

 

[vinylbilt]

Thanks for your ideas. We have keys for every filter we are doing and we don't use LOCATE we use SEEKS, so we do have CDX files. In looking for data, speed is not the issue - we are really more concerned about the amount of data being transferred between the client and the server. Any thoughts on this?

 

[cricket]

You could also have
->faulty network card(s) causing a lot of retransmits
->cat5 cabling for Gigabit
->unnecessary protocols on your server
->mail clients checking their email too frequently
->packet size issues
->refresh rates to high
->tables not opened READ ONLY where data is not being updated

In addition you should check whether the data demand is the same from all workstations, when running the same task. Is there an OS variation beween Vista, Xp and 2000?

 

[DSummZZZ]

'APPEND BLANK followed by GATHER MEMVAR' in itself are somewhat inefficient in that when an APPEND BLANK is issued the record must be added, the DBF header updated, then the indexes and CDX header must be updated to accommodate a blank record.
GATHER MEMVAR then causes the indexes to get updated once again (keys rewritten) to accommodate the 'new' data.

Try using 'INSERT INTO MyTable FROM MEMVAR' instead, and see if it makes a difference. That way, the header and indexes only get updated once.


-Dave Summers-

Even more Fox stuff at:

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

 

[Olaf Doschke]

append blank and or gather memvar can also trigger referential integrity triggers in a dbc's stored procedure, which can do anything and cause any amount of traffic depending on what it does, eg compute some SUM over all data of some other table or whatever.

Bye, Olaf.