> 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
I tried that option and the behaviour doesn't change.. > 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 > > [EMAIL PROTECTED] wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Daad, > >> > >> [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
