From dev-return-106148-apmail-commons-dev-archive=commons.apache.org@commons.apache.org Fri Jan 04 11:10:31 2008 Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 64169 invoked from network); 4 Jan 2008 11:10:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Jan 2008 11:10:30 -0000 Received: (qmail 52330 invoked by uid 500); 4 Jan 2008 11:10:18 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 52236 invoked by uid 500); 4 Jan 2008 11:10:17 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 52226 invoked by uid 99); 4 Jan 2008 11:10:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jan 2008 03:10:17 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kutzi@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 04 Jan 2008 11:09:53 +0000 Received: (qmail invoked by alias); 04 Jan 2008 11:09:56 -0000 Received: from e176024204.adsl.alicedsl.de (EHLO [85.176.24.204]) [85.176.24.204] by mail.gmx.net (mp040) with SMTP; 04 Jan 2008 12:09:56 +0100 X-Authenticated: #383581 X-Provags-ID: V01U2FsdGVkX1/Pk/Qdsz7PjzUPl21zS1Lmnu/GOsczA0wdk0S/Pz p8X2Z/bOvlg60V Message-ID: <477E1401.7080908@gmx.de> Date: Fri, 04 Jan 2008 12:09:53 +0100 From: kutzi@gmx.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [POOL] Offer of help for a 1.4 release References: <4752F4C5.6020403@apache.org> <8a81b4af0712021144mff335e6of6aa465de6ca5e62@mail.gmail.com> <47545EA7.7020201@apache.org> <475C7E6F.6040401@apache.org> <8a81b4af0712091935j13a44e71q651d76c74ba8e077@mail.gmail.com> <20080103092057.60590@gmx.net> <477D3A3B.3020601@apache.org> <8a81b4af0801031809s7969a0fey9e903ae99aefc527@mail.gmail.com> In-Reply-To: <8a81b4af0801031809s7969a0fey9e903ae99aefc527@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org Mark, Thomas, thanks for your replies, Phil Steitz wrote: > On Jan 3, 2008 12:40 PM, Mark Thomas wrote: >> Christoph Kutzinski wrote: >>> - creating a new object means the pool is exhausted which in turn usually means that we have a high-load situation. >>> - creation of new objects is expensive (probably even more in high-load situations). This is why we originally used the pool >>> - so in conclusion it is probably a bad idea to create multiple object in parallel >> I don't see how serializing object creation can help performance. If you >> have a test case and some numbers that show otherwise, I would be very >> interested in taking a look. I have no test case for this, I just have my reasoning and my observation on our live system that connection creation (lets call the 'objects' database connections as that is probably 95% of the use cases of commons-pool :-) ) takes much longer under high load situations: While connection creation in 'idle' mode takes something between 100 and 200 ms, it takes several seconds (the longest I've seen was 27 seconds!) under peak loads. >> >> If you are really worried about the cost of object creation then you can >> configure the pool to create all the objects at start-up and block until a >> free object is available. That is unfortunately not possible under our current configuration as we have set up our application servers to use all connections our database server can handle when their pools have reached their maximum size. For example: we have 40 application servers with a pool max-size of 40. Our database server can just handle (because of its memory configuration) 1600 connections. If we would configure the pools to fetch all connections at startup, we would lose the ability to do updates to our application-software (we have a 2-stage approach to doing updates: we startup the 2nd stage with the new software then configure the load balancer to use the 2nd stage and only afterwards stop the 1st stage) without major hassle. > Thanks for the feedback, Christoph; but I agree with Mark. I suspect > most pool users keep the default whenExhaustedAction, which is to > block. That means that objects get created a) on demand, when there > are no idle instances, but maxActive has not been reached b) when > addObject is invoked to prefill or augment the idle object pool > explicitly or c) when minIdle is set and the idle object evictor runs. > Even when a) happens during a load spike, it is better to do the > makes in parallel, especially if there is some latency involved and > there are resources available to process the makes in parallel (which > will be the case in, e.g. a database connection pool). Phil, I cannot follow your reasoning here. What makes you think that there are "resources available to process the makes in parallel"? What resources do you think of anyway? I'm thinking about resources as processor-cycles on the database server and these are usually not available during peak load times. I still think that serial connection creation is a good thing as it will help to keep unnecessary load from the database server: As connections borrowed from the pool are held only for a comparably short time (at least in our case), the probability that a connection was returned to pool by a different thread in the near future is quite high. So, by serializing connection creation and rechecking, if a connection is available, before starting to create a new one, you won't burden the db-server with unnecessary load. Another thing to consider: If the db-server is under high load, creating connections in parallel probably won't give you any time benefits. While in idle mode it may be true that: When I get 1 connection in 100 ms, I also get n (say 4) connections in ~100ms under high load situations it is much different as all processors on the db-server are busy with other jobs. So it will probably look much more like this: 1 connection in 2 seconds 2 connections in 4 seconds ... So in this case serial creation might be even better from the application side of view, as you already have 1 connection after 2 seconds (the 2nd after 4, and so on), while using parallel creation you would have to wait 4 seconds to get a connection. After all these are all considerations by me without any hard evidence supporting it, besides some observations I made in our live system during peak loads. So you can reject them, if you don't think that they would hold for the majority for the pool clients out there. But I still think that for our use case this would be the best way to proceed. Christoph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org