|
Hein,
it seems that the most direct way to reduce locking and enhance
performance for a file application is to tune :
o bucket' size and number
o global buffer
o local buffer
as you suggested, so what's your checklist when you deal with such
problem ? yes, your approach. what will do first and then next etc. ?
steve
|
| > it seems that the most direct way to reduce locking and enhance
> performance for a file application is to tune :
>
> o bucket' size and number
> o global buffer
> o local buffer
Right, if you can not touch the code. The absolute biggest impact can
normally be made by coming up with a better application algoritme.
> as you suggested, so what's your checklist when you deal with such
> problem ? yes, your approach. what will do first and then next etc. ?
You _have_ to understand the applications dominant access patterns.
If it truly is a sequential scan by primary key, then only bigger
buckets will help. Buffers will not help in that case. In fact, I would
even consider explicitly clearing FAB$W_GBC after SYS$OPEN, before
the SYS$CONNECT to avoid gloabl buffers if they are there for such
special sequential scan case [ and only for the seq read application].
Cheers,
hein.
|