Hi again.

Many thanks to all who have assisted me so far on this issue!

I've tried all of the measures and suggestions that have been sent in:

- set refresh to 0.5 -> seemed to have no effect on the lag
- flush -> also had no effect on the lag
- Set the write back cache on the hard-disk to .f. -> was already disabled
- =rlock() .. unlock on the table -> had no effect

All these ideas helped me move to a couple of other tests, and I have found that if the timer loop actually opens the database table, checks, and then closes the table ...voila! Now, a submitted request is responded to in the same second!!


That seems odd, eh?! Does this provide any ideas as to what I might still be doing wrong? Opening and closing the table every 200 m/secs seems fairly bizarre and strenuous...

However, it IS working at the moment...

Any other thoughts?

TIA Scott :-D


>Hi ho, all!
>
>I am trying to write a process to fulfil a need my client has... Basically, it involves workstations submitting little jobs to a server process... and the server process ( a VFP7) app will do the jobs.
>
>In a test using VFP 7 on a W2K server (766mghz 512 megs of RAM, and EIDE drive & nothing to do :-d)... I wrote a tiny little server test that watches a small jobs table called Test1. It checks the table every 200 m/secs to see if there is a new job to do. Test1.dbf sits on a share that is accessible to the pc's of the lan, but physically exists on the server.
>
>Client side: I write a test prg to open the Test1.dbf on the server (via a share), appends a record, rlocks().. fills it out and the immediately unlocks and closes the table.
>
>The client and server has sync'd time-clocks, so that I can compare submitted datetime() to completed datetime(). In my perfect world, the client should unlock the record, and 200-300 m/secs later, the server would process that record (that's naive expectation, I know, however..)
>
>What I find is that there seems to be a significant lagtime for the server to see the newly created record, obtain its own lock on it and process it.
>
>The lag time varies from 2 secs to 5 secs. But not once did the job complete in the same second as it was submitted. In fact, in about 50 tests, the lag time tends to be 3 & 4 seconds ..in more cases than it is 2 seconds...and this server really has *nothing* to do.
>
>Now, I know that perhaps some reading this may have already chalked this up to the many layers of W2KServer... but my questions are thus:
>
>1. What exactly is the lag?
>2. Can I decrease the lag via settings/config of the server?
>3. Can I decrease the lag via hardware improvements? (wide scsi, or beter)
>4. If there is no tangible ways to improve such a dbf table based approach.. then what
>suggestions are there of *other* ways to create a centralized job engine where speed of
>execution (ie; delivery and acknolwledgement of the job) are highly sought after? .. and have it written in VFP?! :-D
>
>Any advice on the above would be greatly appreciated.
>
>TIA, Scott Barker