Hi james,
>>We have several products in VFP and one legacy app in FP2.6. The optimistic buffering seems to really slow the FP2.6 system down. The combination is WIN2000 server and WIN2000 or XP work station with a newer network card. Opening the tables using VFP vs FPW2.6 is about 15x faster in this environment.
Make sure that you don't draw the wrong conclusions. Whenever a table is openened (either in VFP and FP2.6) for the second time (on different workstations), read and writebuffers might be flushed and turned off by the opportunistic locking scheme of the OS. This indeed causes a notable delay, but is needed to avoid dirty buffers.
You can however tune performance by making static tables readonly, so that the OS of the workstation keeps the already read data of any table in a readbuffer (maintained by the OS, not VFP). Another point that may cause the delay is that tables contained in a DBC requires VFP to read the database also. Since the database can changes during runtime (View and Table definitions, etc.) the database container is also subject to the same problem. Making the database container readonly might improve performance also. Only recently I discovered that a readonly database was 10x faster than a readwrite database when loading a particular (complex) view.
HTH,
Walter,
>>We will replace this legacy app this year with VFP and MSFT SQL. In the meantime, I am wondering how to turn off optimistic buffering. Any help would be greatly appreciated.
>>
>>Regards,
>>
>>JIm Smith
>>>The DELETED() index gets better in over-the-wire operations as the proportion of deleted records increases. If there is no over-the-wire penalty then yes, the index on DELETED() will always help. Otherwise, it's cost/benefit is definitely subject to experimentation for verification.
>>>
>>>**--** Steve
>>>
>>>
>>>
>>>>Dear Steve:
>>>>
>>>>I thought the original wisdom of using the deleted index was to speed things up? Hmm... You are right though, if you are using Foxpro tables, instead of a client server enviroment, then the indexes must come over.
>>>>
>>>>This may account for the slow down we have been experiencing starting up our application on NT based networks with optimistic buffering enabled. Thanks for the thoughts
>>>>
>>>>Regards,
>>>>
>>>>Jim Smith
>>>>>Hi Gord,
>>>>>
>>>>>I've seen this movie before < s >.
>>>>>
>>>>>From what you describe, it clearly looks like the bottleneck is, as typical, the network.
>>>>>
>>>>>I'm sure that if you activate a network monitoring program (like, for example NetMon.EXE) you'll see tens, hundreds, or thousands of megabytes of data going over the wire leading to the workstation. I've seen seemingly bullet-fast local queries dog to a minute or minutes over a network because of hundreds of megabytes of unanticipated network traffic that's obscured by bus traffic when the query is local.
>>>>>
>>>>>The seminal reference to this is an article by Chris Probst in the May 1999 Foxpro Advisor article, "Rushmore Queries: Less is More". Perhaps more imediately handy are these links which discuss related issues:
>>>>>
http://fox.wikis.com/wc.dll?Wiki~NonDiscriminatingIndex>>>>>
http://fox.wikis.com/wc.dll?Wiki~BigSystemPerformanceAndVisualFoxPro>>>>>
http://fox.wikis.com/wc.dll?Wiki~UnderstandingRushmore>>>>>
>>>>>If I were to guess, I would suggest removing any indexes on DELETED() that apply to the major tables involved in the save process. An index on DELETED() is typically a non-discriminating index, all of which Rushmore sucks over the wire for little or no benefit.
>>>>>
>>>>>So in a word, identify and kill (DELETE TAG ...) the most non-discriminating indexes on your larger tables.
>>>>>
>>>>>**--** Steve
>>>>>
>>>>>
>>>>>>I have created an executable and distributed it to the customer. Upon installation, the customer complains about how painfully slow the application is. I am thinking... 2 seconds to perform multiple saves and return control is slow??? What the reality is... at the customer site it will take close to 30 or more seconds to perform a save.
>>>>>>
>>>>>>First thing you think of is, poorly written app, not using Rushmore? I have more than 6 years experience using FoxPro, so my familiarity with the language can be ruled out.
>>>>>>
>>>>>>Details...
>>>>>>
>>>>>>1. The app was developed on a 1.2ghz machine which performs multiple saves in sub 2 second range and returns to the user.
>>>>>>
>>>>>>2. Tested database on machine in a different shop 833mhz, same result.
>>>>>>
>>>>>>3. Tested database on MS Network and app on 833mhz machine in the different shop. Server was over 10 blocks away (Seriously!), same 2 second save.
>>>>>>
>>>>>>4. Tested database and app on Clients workstation 1.6 ghz alone, same 2 second save.
>>>>>>
>>>>>>5. Tested database on Clients network and App on Clients workstation 1.6ghz, 30 to 40 seconds to save.
>>>>>>
>>>>>>
>>>>>>Any ideas... My client has not gotten back to me if they are using Norton AntiVirus or not.
