commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: [Pool] GenericObjectPool performance?
Date Tue, 30 Jul 2002 16:13:06 GMT
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>


Mime
View raw message