oplock performance problem with a small database

[Johann Zuschlag]

On Fri, 09 Jul 1999 14:07:10 -0400, David Collier-Brown wrote:

>Johann Zuschlag wrote:
>> Well, it's just a database residing on a file server. So it will only use smb.
>> It's no intelligent database server like an  SQL-server. But still, searching
>> (with and without index) should be faster. With caching it runs really fast, but
>> that is not save and would only work with one client.
>...
>> It doesn't matter whether there are 2 or 6 users, no speed difference. 
>
>	My understanding is that with oplocks & caching, the
>	files are being shipped to the client once, read there
>	as many times as necessary, and if changed, eventually 
>	shipped back to the server. This should be really fast...

I agree. They are shipped back whenever there is some time or when ending the application.
>
>	With the second user, it should become substantially slower:
>	without caching, an index search means that the file content
>	will be shipped each time to the client, the search done, and 
>	the data discarded.  From what you say, I think that's what's 
>	happening.

Correct.
>
>	Turning off oplocks should show down even single users to this
>	speed.

I agree. Exactly that is happening.
>
>	That speed should stay the same, up to some large number
>	of users, at which point the server or the net gets saturated.
>	This wil lhappen when the number of users makes the demand 
>	more than 1,113 KB/sec on the samba server (on a 10 
>	megabit/sec ethernet). Then it should slow down abruptly.  
>	I doubt if you've hit this second slowdown.

Right! :-)
>
>	If you can separate update use and search use (for example, in
>	a data warehouse), you could use fake oplocks, and have all
>	the clients cache locally.  This assumes you update the
>	database after everyone goes home, though!

I don't agree. Let's assume following scenario with fake oplocks=on:

1) The first user is accessing the dataset X. 
2) The second user is accessing same dataset X.
3) Then the second user changes and saves (updates the database) dataset X.
4) Finally the first user changes and saves (updates the database) dataset X.

The situation is: Both changes happened in the cache of the clients. You will end up with an inconsistent database. I 
tested 
that. That is the reason Windows has to release the cache, when the second user comes on. So you can't update the 
cache overnight. Maybe there are way for a 
more intelligent cache.

And even if you try to separate update and search use it wouldn't work, since the cache would be incorrect.

>
>	A properly tuned real database (including MS-SQL server) 
>	would start out as fast as yours with caching, run at
>	the same speed up to some larger number of users (lots more
>	than 6), then start to degrade gracefully with each additional
>	user.  You'd need to do some tuning initially, to get it fast,
>	then you could ignore it until you had to add a whole bunch more
>	users.   I'd recommend you plan for that in the long term.

SQL is a complety different thing. I agree on that.
>
>	In the short term, you might want to see if you could have
>	a bunch of users using a read-only copy of the database,
>	and another, smaller group with a r/w copy, and update the
>	read-only copy nightly.  

See the above. Wouldn't work.

>	If you were on Solaris, I could help a bit with system 
>	tuning for the pure read-write case, but I doubt we could
>	get it as fast as you see with caching unless the database
>	client was written to be both network- and cache-aware.

Unfortunatley not. I'm using Linux.

But thanks anyway.






























Johann Zuschlag
jozuschlag at online.de