commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <ssand...@nextance.com>
Subject RE: [Pool] GenericObjectPool performance?
Date Tue, 30 Jul 2002 16:35:13 GMT
Agreed.  If you would run performance tests, and possibly submit
patches, that would be great.

I would only like to add a comment here that like Juozas, I like to keep
the number of threads down (150 or less).

Scott

> -----Original Message-----
> From: Juozas Baliuka [mailto:baliuka@mwm.lt] 
> Sent: Tuesday, July 30, 2002 9:13 AM
> To: Jakarta Commons Developers List
> Subject: Re: [Pool] GenericObjectPool performance?
> 
> 
> Hi,
> You will do a great job if you will test GenericObjectPool on 
> 8-processor Solaris, I think the most of us do not have this 
> kind of machines for development.
> 
> 
> 
> ----- Original Message -----
> From: "Jack, Paul" <pjack@sfaf.org>
> To: "'Jakarta Commons Developers List'" 
> <commons-dev@jakarta.apache.org>
> Sent: Tuesday, July 30, 2002 5:22 PM
> Subject: RE: [Pool] GenericObjectPool performance?
> 
> 
> > > It is good to use Pool for threads in this situation, connection 
> > > pool can't increase performance for thousands of concurrent 
> > > transactions. It depends on OS, but any OS has thread 
> limits ( 200 - 
> > > 1000 per CPU  ) I use 30 - 60 per CPU on Linux.
> >
> > The financial institution had thirteen million customers 
> who were able 
> > to use the site.  There'd be thousands of transactions in 
> progress at 
> > any given instant.  Some of those transactions wouldn't require a 
> > database connections, but many would.
> >
> > To handle the load, we used a farm of 8-processor Solaris 
> machines.  
> > Each physical machine was running 2 virtual machines.  The 
> number of 
> > threads per JVM could hit 2000. The pool in each JVM was 
> configured to 
> > use up to 200 connections.  (I think those were the 
> numbers, anyway.)
> >
> > The site worked fine in its initial deployment to a limited 
> audience 
> > of 200,000, but after that success it was deployed to the entire 13 
> > million customer base.  It quickly hit some major problems, and we 
> > were able to determine using a profiler that the connection pool 
> > implementation was a major source of damage.  Basically the 
> > synchronized blocks were too long, and the use of 
> notifyAll() that the 
> > pool required greatly increased the monitor contention.
> >
> > By switching the pool implementation with something less 
> complex but 
> > more efficient, we resolved a large portion of the performance 
> > problems we were experiencing.  I remember the faulty 
> implementation 
> > used a doubly linked list, something similar to 
> GenericObjectPool. I 
> > no longer have access to the code though so I don't know 
> exactly how 
> > similar they are.  If GenericObjectPool's been tested for 
> performance 
> > and it seems to scale, I'll shut up about it, otherwise 
> I'll volunteer 
> > to run some tests myself.
> 
> 
> >
> > -Paul
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message