Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 53339 invoked from network); 30 Jul 2002 16:09:08 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 30 Jul 2002 16:09:08 -0000 Received: (qmail 17432 invoked by uid 97); 30 Jul 2002 16:09:27 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 17389 invoked by uid 97); 30 Jul 2002 16:09:26 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 17377 invoked by uid 98); 30 Jul 2002 16:09:26 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <05f401c237e3$fd431110$a901a8c0@juozas> From: "Juozas Baliuka" To: "Jakarta Commons Developers List" References: Subject: Re: [Pool] GenericObjectPool performance? Date: Tue, 30 Jul 2002 18:13:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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" To: "'Jakarta Commons Developers List'" 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: > For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: