tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smith <d...@cornell.edu>
Subject Re: Connection pooling again
Date Wed, 09 Apr 2008 21:45:19 GMT
I haven't looked at the source, but I'm willing to bet there is at least 
one sync block -- the pooling implementation would have to perform a 
brief sync when it borrows a connection object from the pool.  In 
addition, if this is from a fresh startup of tomcat without a minIdle 
setting (default=0) in your Resource definition (I didn't see one in 
your original post), each parallel call to getConnection() will mean 
creating a new connection to the db because all previous connections are 
busy and none are being reused.

I'd be curious what this would look like with:
  a) a minIdle setting to establish a pool of connections on startup and
  b) if the threads kept going over a few iterations releasing and 
reacquiring connections.  Would the time keep going up or would it drop 
as connections start getting reused?

--David

daad@libero.it wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Daad,
>>
>> daad@libero.it wrote:
>> | i think i don't get the utility of a connection pooling, since i have
>> this situation: 30 threads try to perform at same time a db access with
>> the call:
>> |
>> | new Database().doSomething()
>>
>> Are you sure you're using your Database class in this way? I wouldn't be
>> surprised if you are creating a single Database object and using it
>> repeatedly.
>>     
>
> Yes i'm sure, i'm using (new Database()).doSomething() always.
>
>   
>> Are your threads actually running in parallel?
>>
>>     
>
> That's my question.
>
>   
>> | [wed, 09 apr 2008 00:55:03] INFO	Database -> doSomething: 836
>> | [wed, 09 apr 2008 00:55:04] INFO	Database -> doSomething: 1444
>> | [wed, 09 apr 2008 00:55:04] INFO	Database -> doSomething: 2054
>> | [wed, 09 apr 2008 00:55:05] INFO	Database -> doSomething: 2417
>> | [wed, 09 apr 2008 00:55:05] INFO	Database -> doSomething: 3060
>> | [wed, 09 apr 2008 00:55:06] INFO	Database -> doSomething: 3647
>> | [wed, 09 apr 2008 00:55:07] INFO	Database -> doSomething: 4279
>> | [wed, 09 apr 2008 00:55:07] INFO	Database -> doSomething: 4967
>> | [wed, 09 apr 2008 00:55:08] INFO	Database -> doSomething: 5592
>> | [wed, 09 apr 2008 00:55:09] INFO	Database -> doSomething: 6208
>> | [wed, 09 apr 2008 00:55:09] INFO	Database -> doSomething: 7026
>> | [wed, 09 apr 2008 00:55:10] INFO	Database -> doSomething: 7455
>> | [wed, 09 apr 2008 00:55:10] INFO	Database -> doSomething: 8087
>> | [wed, 09 apr 2008 00:55:11] INFO	Database -> doSomething: 8705
>> | [wed, 09 apr 2008 00:55:12] INFO	Database -> doSomething: 9318
>> | [wed, 09 apr 2008 00:55:12] INFO	Database -> doSomething: 10040
>> | [wed, 09 apr 2008 00:55:13] INFO	Database -> doSomething: 11146
>> | [wed, 09 apr 2008 00:55:14] INFO	Database -> doSomething: 11702
>> | [wed, 09 apr 2008 00:55:14] INFO	Database -> doSomething: 12033
>> | [wed, 09 apr 2008 00:55:15] INFO	Database -> doSomething: 12658
>> | [wed, 09 apr 2008 00:55:16] INFO	Database -> doSomething: 13279
>> | [wed, 09 apr 2008 00:55:16] INFO	Database -> doSomething: 13897
>> | [wed, 09 apr 2008 00:55:17] INFO	Database -> doSomething: 14523
>> | [wed, 09 apr 2008 00:55:17] INFO	Database -> doSomething: 15139
>> | [wed, 09 apr 2008 00:55:18] INFO	Database -> doSomething: 15759
>> | [wed, 09 apr 2008 00:55:19] INFO	Database -> doSomething: 16411
>> | [wed, 09 apr 2008 00:55:19] INFO	Database -> doSomething: 17056
>> | [wed, 09 apr 2008 00:55:20] INFO	Database -> doSomething: 17672
>> | [wed, 09 apr 2008 00:55:20] INFO	Database -> doSomething: 18292
>>
>> Every single operation takes more time than the previous operation. That
>> smells of a problem with resetting a counter. Isn't it interesting that
>> the logging statements show that all 30 threads completed within 18
>> seconds of each other, and each thread says that it took up to 18
>> seconds to complete? If these processes were sharing a single
>> connection, and they were taking 18 seconds to complete, the total time
>> would be 9 minutes, not 18 seconds.
>>
>>     
>
> As you can see from the code i pasted, start time is taken in getConnection() method
and end time is taken in closeResources() method. So from the logs i understand that all 30
threads arrive in getConnection() at same time (so all "start" variable of each Database instance
is set to same timestamp (about)), but then seems that operation get enqueued, since the first
thread that is able to quit needs 836ms, while the last one 18292ms. That means the second
thread that can perform the query waited that first thread complete the query. So, even if
the second thread arrived to getConnection() at same time of the first, the second took almost
double time because waited that the first complete the task. That's what i understood from
logs... I didn't get what you said about 9 minutes. If the operation takes 600-800ms (as first
thread demonstrate), 30 x 600 = 18000ms. So with one connection, if those 30 threads are enqueued,
the total time is 18 seconds, that is what happens. So i still think that one connection is
shared only =\
>
> If anybody know what to check on Mysql application to see if there is a sort of limitation
on number of concurrent queries, please let me know.
>
>   
>> Even if you had resource contention (which you shouldn't have with 600
>> shared connections), I would expect that some numbers would be low and
>> others were high -- essentially randomly distributed.
>>
>> It's pretty clear to me that something else is going on... I'm guessing
>> that the connection pool (which one are you using?) is working just
>> fine, but either your "load test" code or your server-side database use
>> is being incorrectly used and/or incorrectly instrumented.
>>
>>     
>
> I'm using mysql-connector-java-5.1.5-bin.jar
>
>   
>> | so i can't understand the meaning of maxActive parameter.. i thought
>> | that could be at most 600 concurrent connection.
>>
>> ~From the documentation: "The maximum number of active connections that
>> can be allocated from this pool at the same time, or negative for no limit."
>>
>> Your expectation that 600 connections should be available is correct.
>> Although, 600 connections in a connection pool is a /lot/ of connections. ;)
>>
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkf8yAkACgkQ9CaO5/Lv0PAGtgCeL5O0jUrxfZZZM/3ix3pbmrWV
>> kgcAnR1wlDWpS9ez9FE/uNHzKptqTCmc
>> =mSOU
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>     
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>   



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message