write caching?

[Nigel Gomm]

i have an application that uses a table as a message queue with client PCs putting a request in the table (new record) and an .exe on a server listening for requests and writing the reply. Been working well for several years at a variety of customers with different versions of Windows Server (SMB2, oplocks etc should be switched off).

The server .exe uses
[pre]
UNLOCK in tablename
FLUSH IN tablename FORCE
[/pre]
to make sure the record physically gets updated asap.

Recently (last month or so) performance at several customers slumped and it seemed that the client PCs weren't seeing the reply for several seconds. Separately when trying to open the table at start of day they often got stuck with "attempting to lock".

In desperation i replaced the UNLOCK and FLUSH with
[pre]USE IN tablename
USE tablename
[/pre]
and it appears much (much!) quicker (The table is small with just the one index so reopening should be quick). It's early days yet and i don't have a formal test or measurement for the improvement (plus i made few changes to the AV).... but it seemed quicker to me when i was testing

I'm wondering if a recent Windows update has changed something.....

Any thoughts ?

n

 

[Olaf Doschke]

In regard of recent changes: No idea. In regard of problems with locks, I had worse situations in a large corporate LAN with old and new cabling and token ring and several hubs and backbones of changes not seen for many minutes, that was also in an application doing pessimisitc locking, manually with RLOCK, not via a pessimistic buffermode, the lock was made by a navbar edit mode button, quite likely the original code came from the ffc navbar and was modified over years.

Bye, Olaf.

 

[GriffMG]

Could it be our old favourite opportunistic file locking?

Symptoms sound a bit like it, some people can't open a table once another user has opened it, updates not visible...

What was the recent windows update?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Nigel Gomm]

Olaf... all the tables are unbuffered because i don't bind any screen controls directly to a table (all controls bind to a custom dataobject which does its own optimistic locking).


Griff.... i don't know of any specific updates - just that several customers have started suffering from this so my first reaction, as always, is to blame someone else ;-) It may just be that something is undoing the oplocks setting.


this particular routine does a brief rlock() when updating a record then unlocks immediately.... the rlock() is probably unnecessary in that the REPLACE will automatically do it anyway. And then it skips to next record so it should get written out as well. The rlock(), unlock and flush are just belt and braces. i tried without the rlock() but no discernible difference.

i'm wondering if cursorsetprop("buffering",3) with an explicit TABLEUPDATE() would do anything different?



n

 

[Olaf Doschke]

Buffering is not only useful, when binding data to controls. It's keeping changes locally ,until you want to submit them, that's the main advantage of it, also in mere non visual server side processes and even if the amount of buffering is limited to single records, it's less essantial to buffer changes, if the data changes are not complex, but of course 10 replaces of 10 single fields buffered and then one tableupdate causing one record update does less locks and unlocks, and uses less network protocol than 10 unbuffered replaces.

If things have worked for a long time and suddenl show problems at man customers the reasoning is ok, to suspect a change by something like a windows update. The onl other thing always changing is the amounnt of data. The growth typically is slow, but still sudden problems can occur, not only hitting the 2gb limit can be a sudden impact. But it's unlikely to happen at many customers at the same time, each customer will have their individual data growth.

Bye, Olaf.

 

[Nigel Gomm]

if anyone is interested in the outcome of this....

the reason i was seeing issues at so many unrelated customers appears to have been my process running as "below normal priority" - and that probably because it was launched indirectly by task scheduler. A quick google suggests that diskwrites would be the first casualty when running like this.

So
DECLARE INTEGER GetCurrentProcess IN Win32api
DECLARE SetPriorityClass IN WIN32API INTEGER , INTEGER
SetPriorityClass(GetCurrentProcess(),0x00000020) && normal

at startup seems to have sorted it.


hope this helps someone in the future...

n

 

[Mike Lewis]

Olaf makes a good point when he talks about buffering.

I had a similar experience a few years ago. I had a foreground program that wrote data to a table, and a background program that periodically polled the table to read the data. I found that the only way to ensure that the background program always saw the new data in the table was to use CURVAL() to read the values. And of course that requires a buffer mode to be set.

Nigel, this is probably not relevant in your case, as I see you have found a different solution, but it might be worth keeping in mind.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Nigel Gomm]

Mike, in my case CURVAL() probably wouldn't have worked because it seemed to be the write that wasn't happening.... but interesting nonetheless.

Olaf, good point about the single write but that was the case anyway in this particular application. i did try with buffering set to 3 and using tableupdate() but no difference.


n