On 14/09/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote:
> Thanks again Sebb:
>
>
>
> >How many threads have you got?
>
> >
>
> >If you want your threads to act as independent users, then you should
>
> >set the pool size to be at least as big. This should prevent the
>
> >timeouts.
>
>
>
> Thanks Sebb. I have a maximum of about 1500 concurrent threads. A JDBC
> thread pool that large isn't feasible, right? :{
>Dunno - try it and see. I doubt that the connection objects take up lots of memory. It may place a large strain on the server - but that is what you are trying to test ... > Generally speaking, how do thread pools interact with databases. I'll > ask my DBA about this too :) but do databases (in my case, Oracle) > specify connection limit that limit a practical JMeter the thread pool > sizes? In my case, I'm running 10-15 JMeter instances concurrently each > with a JDBC thread pool set to 10 threads (for now). So when they run, I > guess 150 connections open to the DB? I guess I cannot increase them all > to 60 without speaking to my DBA. :-) -- right? Yes, you'll need one connection per pool entry. If you are trying to test the database, you need to try and use as many connections as the real-life scenario you are trying to emulate. > > > The Java application we are simulating has JDBC thread pool size set to > 20. Since JMeter is testing at 3x normal load, should I set the JMeter > pool size to 60? Upping the JMeter thread pool from 10 to 25 still > resulted in the error. Depends on whether you are trying to test SQL traffic increasing 3 times, but still using 20 connections, or whether you also want to test increasing the pool count. > > > > > > >Otherwise threads may have to wait for up to the Pool timeout - which > > >does seem to be what is happening here. > > > > > > > What are your thoughts on increasing timeout as opposed to increasing > the pool size? I guess this affects performance testing as threads will > no longer strictly follow the ramp up time as they will queue up longer. > > The ramp-up time applies before the threads perform any JDBC requests. > > I also found a new exception: SQL 'Io exception' in a load test I > recently ran. > > ---------- > > <sampleResult timeStamp="1189587196968" dataType="" threadName="Load > Test Thread Group 1-276" label="JDBC Request - check pick ticket header > made it to ..." time="79" responseMessage="java.sql.SQLException: Io > exception: The Network Adapter could not establish the connection" > responseCode="" success="false"><assertionResult > failureMessage="Response was null" error="false" > failure="true"/></sampleResult> > > ----------- > > Any idea about this? This exception only occurs once or twice (in about > 30000 requests). The NoAvailableConnectionException has thousands of > entries in the logs. > Looks to be a lack of network or host resources. > > Kind regards, > > Sonam Chauhan > > -- > > Corporate Express Australia Ltd. > > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > > > > > > > -----Original Message----- > > From: sebb [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, 12 September 2007 8:05 PM > > To: JMeter Users List > > Subject: Re: JDBC NoAvailableConnectionException Problem > > > > How many threads have you got? > > > > If you want your threads to act as independent users, then you should > > set the pool size to be at least as big. This should prevent the > > timeouts. > > > > Otherwise threads may have to wait for up to the Pool timeout - which > > does seem to be what is happening here. > > > > [I'm not sure that Pooling is appropriate for JMeter ... we probably > > need to add an option to have per-thread connection handling, and > > allow manual connect and disconnect]. > > > > As to idle cleanup interval, I assume that is how long a connection > > can be idle before it is closed, and therefore affects how often the > > connections have to be recycled. > > > > If you are trying to simulate real clients, then arrange the interval > > so that it corresponds with when they would reconnect. > > > > If you are not interested in connection overhead, then set the > > interval higher than the max likely idle period. > > > > S. > > On 12/09/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > > > Hello JMeter Users: > > > > > > > > > > > > I have a 'heavy' test that uses the 'JDBC Sampler' - it executes about > > > 4000 JDBC requests in 600 seconds. However, it throws > > > NoAvailableConnectionException errors. Here is a sample log entry: > > > > > > ------------------- > > > > > > <sampleResult timeStamp="1189567551455" dataType="" threadName="Surge > > > Test Thread Group 2-2041" label="Insert a pick ticket ..." > time="10001" > > > > responseMessage="org.apache.avalon.excalibur.datasource.NoAvailableConne > > > ctionException: Could not create enough Components to service your > > > request (Timed out)." responseCode="" success="false"><assertionResult > > > failureMessage="Response was null" error="false" > > > failure="true"/></sampleResult> > > > > > > ------------------- > > > > > > > > > > > > The top of the test plan has a 'JDBC Connection Configuration' element > > > with these settings. > > > > > > Max. Number of connections = 10 > > > > > > Pool timeout = 10000 (I assume this caused the error abobe) > > > > > > Idle Cleanup Interval (ms) = 60000 > > > > > > These and all the other settings for this config element are the > default > > > values > > > > > > > > > > > > Can anyone advise me how I can address this error? > > > > > > Each of my test thread 'sleeps' for about 6 minutes to allow > > > transactions to propagate from source to destination systems -would > > > impact Idle Cleanup Interval? > > > > > > Would I increase the max number of number of connections & timeout, > and > > > decrease idle cleanup interval? > > > > > > > > > > > > Kind regards, > > > > > > Sonam Chauhan > > > > > > -- > > > > > > Corporate Express Australia Ltd. > > > > > > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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]
