On Tuesday 28 August 2001 12:17, Greg Stein wrote:
> On Mon, Aug 27, 2001 at 05:09:01PM -0700, Aaron Bannert wrote:
> > This patch implements a resource pool of context pools -- a queue of
> > available pools that the listener thread can pull from when accepting
> > a request. The worker thread that picks up that request then uses
> > that pool for the lifetime of that transaction, clear()ing the pool
> > and releasing it back to what I'm calling the "pool_queue" (har har).
> > This replaces the prior implementation that would create and destroy
> > a transaction pool for each and every request.
> >
> > I'm seeing a small performance improvement with this patch, but I suspect
> > the fd_queue code could be improved for better parallelism. I also
> > suspect that with better testing this algorithm may prove more scalable.
>
> What does "small" mean?
>
> I can't believe it is all that large. Pool construction/destruction is
> actually quite fast. The bulk of the time is clearing the pool, which you
> must do anyways. I don't see how a pool queue can provide any benefit.
>
> IOW, why should this complexity be added? Just how much does it improve
> things, and are you testing on a single or multi processor machine?
Creating a pool requires locking a mutex. The more we scale, the worse we
perform.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
