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 15:22:02 GMT
> 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>


Mime
View raw message