Re: Proposal of tunable fix for scalability of 8.4

On Thu, Mar 12, 2009 at 3:13 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>>>> Scott Carey <scott(at)richrelevance(dot)com> wrote:
>> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>>
>>> I'm a lot more interested in what's happening between 60 and 180
>>> than over 1000, personally.  If there was a RAID involved, I'd put
>>> it down to better use of the numerous spindles, but when it's all
>>> in RAM it makes no sense.
>>
>> If there is enough lock contention and a common lock case is a short
>> lived shared lock, it makes perfect sense sense.  Fewer readers are
>> blocked waiting on writers at any given time.  Readers can 'cut' in
>> line ahead of writers within a certain scope (only up to the number
>> waiting at the time a shared lock is at the head of the queue).
>> Essentially this clumps up shared and exclusive locks into larger
>> streaks, and allows for higher shared lock throughput.
>
> You misunderstood me.  I wasn't addressing the affects of his change,
> but rather the fact that his test shows a linear improvement in TPS up
> to 1000 connections for a 64 thread machine which is dealing entirely
> with RAM -- no disk access.  Where's the bottleneck that allows this
> to happen?  Without understanding that, his results are meaningless.

I think you try to argue about oranges, and he does about pears. Your
argument has nothing to do with what you are saying, which you should
understand.
Scalability is something that is affected by everything, and fixing
this makes sens as much as looking at possible fixes to make raids
more scalable, which is looked at by someone else I think.
So please, don't say that this doesn't make sense because he tested it
against ram disc. That was precisely the point of exercise.

--
GJ