Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
From: "Mark Imel" <locrian@imelshire.com>
To: "'Apache Directory Developers List'" <directory-dev@incubator.apache.org>
Subject: RE: RE: [eve] A Buffer Pool (of direct mapped buffers)
Date: Tue, 2 Dec 2003 21:54:10 -0800
Message-ID: <000001c3b961$df626640$7e1ba8c0@Primer>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: 
 <20031203053021.EAZM1942.imf23aec.mail.bellsouth.net@mail.bellsouth.net>

There's a couple of main reasons why we use a per thread pool.
One is that we have a finite set of threads in our server, so if we use
ThreadLocalStorage, there's a good chance that whatever we store on that
thread we'll get to use again.

Secondly, having a per thread pool, removes any synchronization
overhead.  In fact, if you own the thread, you can even pre-create slots
on the Thread to prevent hashMap lookups for your TLS.

Now, I'll be the first to admit that the newer VM's have greatly
improved the performance regarding synchronization, so if you want to be
sure that perThread is faster, or slower, you'll need to run your own
tests.

Also, during long discussions regarding pooling in general, I have to
admit, that you can be putting a burden on the Garbage collector.  In my
experience, it's been well worth it, and the stability as well as memory
management of our server have improved as a result.

I've found that object pooling, (and caching!) are very difficult
concepts to implement correctly, and I've certainly made my share of
mistakes... I probably still am...

Feel free to ask about specifics if I've been to vague.
Regards,
--mark imel

-----Original Message-----
From: Alex Karasulu [mailto:aok123@bellsouth.net] 
Sent: Tuesday, December 02, 2003 9:30 PM
To: Apache Directory Developers List
Subject: Re: RE: [eve] A Buffer Pool (of direct mapped buffers)


Mark,

I have an employer or two that would love to talk to you :-).  

> >So in a way ironically we're imposing buffer management in
> >a garbage collected language :-) to get better performance.
> 
> >Thoughts?
> 
> I write Enterprise portals in java that have massive RASUI 
> requirements... Reliability, Availability, Scalability, etc... Your 
> typical enterprise Uptime requirements.  One of the most important 
> ways we accomplish this is by pooling buffers, and data structures... 
> Of course, we have optimized ways of checking out and checking in the 
> objects (Per Thread pools), but I 100% agree with your statement 
> above.

Why a pool per thread group? I have some ideas (i.e. thread pool to 
buffer pool ratio management becomes easier) but I'm interested in
understanding your POV.  Any input on this topic or help would be
welcome. 

Thanks for the interest/commentary,
Alex