commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <pj...@sfaf.org>
Subject RE: [Pool] GenericObjectPool performance?
Date Tue, 30 Jul 2002 17:07:37 GMT
Um...to be clear, I no longer have access to the hardware
wonderland.  That was a contract job and the contract expired,
and anyway I made major life decisions and so on.  I now
work at a nonprofit whose toys aren't nearly as interesting. :)

But I could probably pull strings to have someone over at
the bank run a test suite for me, maybe.  

Does anybody know how TomCat is tested?  I imagine they do 
performance stuff, yes?

-Paul


> -----Original Message-----
> From: Scott Sanders [mailto:ssanders@nextance.com]
> Sent: Tuesday, July 30, 2002 9:35 AM
> To: Jakarta Commons Developers List
> Subject: RE: [Pool] GenericObjectPool performance?
> 
> 
> 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>

--
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