Thought I'd jump in... :^) Regarding JDBC connections pools in load testing, here's an earlier conversation where Sebb mentioned this http://snipurl.com/1qn0x
Yes! per-thread connection handling is a good idea. The main question I have though, is will the extra per-thread DB connection setup and teardown expense be low enough to not make a difference to both: (a) Jmeter (b) The database being tested I think it's a good idea to have both mechanisms available. Kind regards, Sonam Chauhan -- Corporate Express Australia Ltd. Phone: +61-2-93350725, Email: [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 5 January 2007 5:54 AM To: JMeter Users List Subject: Re: JDBC connection pooling - should it be used at all? Ah, that is a good point. Do you know if the connection pool is initialized before the Thread Group is started when using a JDBC Connection Configuration element? If so, the only real benefit I could see for using the connection pool is to prevent the small amount of initial overhead caused by each thread creating their own connection. Not a very compelling benefit :) Skyler Bingham [EMAIL PROTECTED] (602) 957-1650 x1139 sebb <[EMAIL PROTECTED]> wrote on 01/04/2007 11:24:42 AM: > Yes, it is expensive to create new connections, but it would only have > to be done once for each thread. > > If there are several threads doing database samples and not much else, > then it is likely that there will need to be one connection per thread > anyway to avoid threads having to wait for a connection to become > available. > > This can be "solved" by making the thread pool at least as big as the > number of threads, but then there is not really any need for the > pool... > > JMeter could be changed to make the connection pool optional. > > I just wonder whether JMeter really needs the pooling code at all. > > S/// > On 04/01/07, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > It only matters from a performance perspective, because it would be > > expensive to create new connections for each thread. Because I am not > > testing the database, it doesn't really matter if the connections are > > shared. I can see a case for using a connection pool for load testing a > > database though, because creating DB connections is expensive, and the > > shared connection pool would allow "users" (threads), to spend more time > > slamming the DB and less time managing connections. > > > > Skyler Bingham > > [EMAIL PROTECTED] > > (602) 957-1650 x1139 > > > > sebb <[EMAIL PROTECTED]> wrote on 01/04/2007 04:30:46 AM: > > > > > Interesting - of course one could do it all in BeanShell, but saves > > > code to do it your way. > > > > > > Does it matter to you whether or not the connections are shared > > > between threads? > > > > > > > > > On 03/01/07, [EMAIL PROTECTED] > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > I use the JDBC Connection Configuration element to define a connection > > > > pool, then use the pool to access database resources via beanshell to > > add > > > > some "intelligence" to my load tests. This allows me to script dynamic > > > > load tests that can behave differently depending on the state of the > > > > application, users, etc. This is probably not it's intended use, but > > it > > > > comes in handy. > > > > > > > > This e-mail and files transmitted with it are confidential, and are > > intended solely for the use of the individual or entity to whom this e-mail > > is addressed. If you are not the intended recipient, or the employee or > > agent responsible to deliver it to the intended recipient, you are hereby > > notified that any dissemination, distribution or copying of this > > communication is strictly prohibited. If you are not one of the named > > recipient(s) or otherwise have reason to believe that you received this > > message in error, please immediately notify [EMAIL PROTECTED] > > by e-mail, and destroy the original message. Thank You. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > This e-mail and files transmitted with it are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you are not one of the named recipient(s) or otherwise have reason to believe that you received this message in error, please immediately notify [EMAIL PROTECTED] by e-mail, and destroy the original message. Thank You. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
