You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Henrik Rathje <hr...@ki.tng.de> on 2004/09/10 19:35:43 UTC
Re: DBCP Performance -> solved.
Hi,
i did not change any settings, no restart and no anything; but now the timings are:
67 miliseconds pool
956 miliseconds nopool.
seems it simply takes several minutes until the pool is ready to use.
sorry for asking those stupid questions + thanks for helping,
Henrik
On Fri, 10 Sep 2004 12:16:18 -0500
Peter Lin <wo...@gmail.com> wrote:
> I used oracle's drivers :)
>
> since I'm most experienced with Oracle and I have it installed at home
> for development.
>
> peter
>
>
> On Fri, 10 Sep 2004 19:11:53 +0200, Henrik Rathje <hr...@ki.tng.de> wrote:
> > hi,
> > im note sure if there exists another jdbc driver for ingres beside
> > the one i use. can this really be a driver issue?
> > which connectionpool did you use while doing the measurements for your
> > 'so you want high performance' paper?
> > regards, henrik
> >
> > On Fri, 10 Sep 2004 12:02:13 -0500
> >
> >
> > Peter Lin <wo...@gmail.com> wrote:
> >
> > > wow, that just seems wrong. Have you tried other jdbc drivers? I know
> > > from first hand experience with Oracle's jdbc driver, w/o pooling it's
> > > minimum of 100ms to get connection. With pooling, it's usually less
> > > than 5ms.
> > >
> > > peter
> > >
> > >
> > > On Fri, 10 Sep 2004 18:56:42 +0200, Henrik Rathje <hr...@ki.tng.de> wrote:
> > > > I have to correct myself:
> > > > getNumIdle() returned 19 after a little bit of waiting.
> > > > but getConnection( ) still takes 1238 miliseconds.
> > > > Henrik
> > > >
> > > > On Fri, 10 Sep 2004 18:47:46 +0200
> > > >
> > > >
> > > > Henrik Rathje <hr...@ki.tng.de> wrote:
> > > >
> > > > > Hi,
> > > > > I tried your settings, but getNumIdle() still returns 0.
> > > > > Why that?
> > > > > The maxActive value was 0 because i thought this is neccesary to let
> > > > > the pool never run out of connections:
> > > > > http://jakarta.apache.org/commons/dbcp/configuration.html
> > > > > maxActive default:8 The maximum number of active connections that can be allocated from this pool at the same time, or zero for no limit.
> > > > > cheers, Henrik
> > > > >
> > > > > On Fri, 10 Sep 2004 12:23:40 -0400
> > > > > "Shapira, Yoav" <Yo...@mpi.com> wrote:
> > > > >
> > > > > >
> > > > > > Hi,
> > > > > > Try minIdle = 19, maxIdle = 20, maxActive = 20, initialSize = 20. I
> > > > > > think the maxActive 0 effectively means no pooling.
> > > > > >
> > > > > > Yoav Shapira
> > > > > > Millennium Research Informatics
> > > > > >
> > > > > >
> > > > > > >-----Original Message-----
> > > > > > >From: Henrik Rathje [mailto:hrathje@ki.tng.de]
> > > > > > >Sent: Friday, September 10, 2004 12:20 PM
> > > > > > >To: Tomcat Users List
> > > > > > >Subject: Re: DBCP Performance?
> > > > > > >
> > > > > > >Hi,
> > > > > > >seems you are rite:
> > > > > > >
> > > > > > >org.apache.commons.dbcp.BasicDataSource source =
> > > > > > >(org.apache.commons.dbcp.BasicDataSource)ds;
> > > > > > > System.out.println("num of idle connections " +
> > > > > > source.getNumIdle()
> > > > > > >);
> > > > > > > System.out.println("num of max act connections " +
> > > > > > >source.getMaxActive() );
> > > > > > > System.out.println("username " + source.getUsername() );
> > > > > > >
> > > > > > >prints:
> > > > > > >num of idle connections 0
> > > > > > >num of max act connections 0
> > > > > > >username tomcat
> > > > > > >
> > > > > > >but why? here is the connection pool configuration:
> > > > > > ><Resource name="jdbc/sdb-login" auth="Container"
> > > > > > > type="javax.sql.DataSource"/>
> > > > > > >
> > > > > > > <ResourceParams name="jdbc/sdb-login">
> > > > > > > <parameter>
> > > > > > > <name>factory</name>
> > > > > > > <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>driverClassName</name>
> > > > > > > <value>ca.edbc.jdbc.EdbcDriver</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>poolPreparedStatements</name>
> > > > > > > <value>true</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>defaultAutoCommit</name>
> > > > > > > <value>false</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>url</name>
> > > > > > > <value>jdbc:edbc://localhost:IJ7/sdb</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>username</name>
> > > > > > > <value>tomcat</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>password</name>
> > > > > > > <value>passwd ;-)</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>initialSize</name>
> > > > > > > <value>20</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>maxActive</name>
> > > > > > > <value>0</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>maxIdle</name>
> > > > > > > <value>0</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>minIdle</name>
> > > > > > > <value>20</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>maxWait</name>
> > > > > > > <value>-1</value>
> > > > > > > </parameter>
> > > > > > > <parameter>
> > > > > > > <name>testOnBorrow</name>
> > > > > > > <value>false</value>
> > > > > > > </parameter>
> > > > > > > </ResourceParams>
> > > > > > >
> > > > > > >Thanks for support, Henrik
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >On Fri, 10 Sep 2004 11:51:05 -0400
> > > > > > >"Shapira, Yoav" <Yo...@mpi.com> wrote:
> > > > > > >
> > > > > > >>
> > > > > > >> Hi,
> > > > > > >> Hmm, with minIdle set to 20 and assuming your test gets one
> > > > > > connection
> > > > > > >> at a time (or less than 20 at a time), I'm a bit confused.
> > > > > > >>
> > > > > > >> One next step would be to really verify that the pool has available
> > > > > > >> connections before the get connection call. You obviously wouldn't
> > > > > > do
> > > > > > >> this in a production application, but this is just for debugging a
> > > > > > >> performance test. Cast the DataSource to the concrete implementation
> > > > > > >> type, probably org.apache.commons.dbcp.BasicDataSource, and call
> > > > > > >> getNumIdle on it to verify it's a positive number before calling
> > > > > > >> getConnection. If it's zero or negative your pool is misconfigured
> > > > > > and
> > > > > > >> you're creating a new connection, hence the slow performance.
> > > > > > >>
> > > > > > >> Yoav Shapira
> > > > > > >> Millennium Research Informatics
> > > > > > >>
> > > > > > >>
> > > > > > >> >-----Original Message-----
> > > > > > >> >From: Henrik Rathje [mailto:hrathje@ki.tng.de]
> > > > > > >> >Sent: Friday, September 10, 2004 11:46 AM
> > > > > > >> >To: Tomcat Users List
> > > > > > >> >Subject: Re: DBCP Performance?
> > > > > > >> >
> > > > > > >> >Hi,
> > > > > > >> >The minIdle value during this test was:
> > > > > > >> ><parameter>
> > > > > > >> > <name>minIdle</name>
> > > > > > >> > <value>20</value>
> > > > > > >> ></parameter>
> > > > > > >> >any other suggestions?
> > > > > > >> >Thanks in advance, Henrik
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >On Fri, 10 Sep 2004 11:21:08 -0400
> > > > > > >> >"Shapira, Yoav" <Yo...@mpi.com> wrote:
> > > > > > >> >
> > > > > > >> >>
> > > > > > >> >> Hi,
> > > > > > >> >> The initial connections can be closed if idle, depending on your
> > > > > > pool
> > > > > > >> >> configuration, so you might be creating new connections each time
> > > > > > >> even
> > > > > > >> >> with the pool. Check your minIdle setting.
> > > > > > >> >>
> > > > > > >> >> If you're creating a new connection each time, a tiny bit of
> > > > > > overhead
> > > > > > >> >> can be expected for a pool over a direct DriverManager call. But
> > > > > > >> that
> > > > > > >> >> defeats the purpose of pooling. If your pool is properly
> > > > > > configured
> > > > > > >> and
> > > > > > >> >> has a connection waiting, it should be a little bit more than a
> > > > > > hash
> > > > > > >> >> lookup to return the connection, which would be significantly
> > > > > > faster
> > > > > > >> >> than creating a new one.
> > > > > > >> >>
> > > > > > >> >> Yoav Shapira
> > > > > > >> >> Millennium Research Informatics
> > > > > > >> >>
> > > > > > >> >>
> > > > > > >> >> >-----Original Message-----
> > > > > > >> >> >From: Henrik Rathje [mailto:hrathje@ki.tng.de]
> > > > > > >> >> >Sent: Friday, September 10, 2004 11:16 AM
> > > > > > >> >> >To: tomcat-user@jakarta.apache.org
> > > > > > >> >> >Subject: DBCP Performance?
> > > > > > >> >> >
> > > > > > >> >> >Hi,
> > > > > > >> >> >has enyone of you recently measured the performance of the DBCP
> > > > > > >> >> >Connection Pool? I compared
> > > > > > >> >> >
> > > > > > >> >> ><snip>
> > > > > > >> >> >long start = System.currentTimeMillis();
> > > > > > >> >> >Class.forName("ca.edbc.jdbc.EdbcDriver");
> > > > > > >> >> >Connection dbcon = DriverManager.getConnection(loginUrl,
> > > > > > loginUser,
> > > > > > >> >> >loginPa$
> > > > > > >> >> >long diff = System.currentTimeMillis() - start;
> > > > > > >> >> >System.out.println("creating connection without pool took: " +
> > > > > > diff
> > > > > > >> + "
> > > > > > >> >> >mil$
> > > > > > >> >> ></snip>
> > > > > > >> >> >
> > > > > > >> >> >with
> > > > > > >> >> >
> > > > > > >> >> ><snip>
> > > > > > >> >> >long start = System.currentTimeMillis();
> > > > > > >> >> >Connection dbcon = ds.getConnection( );
> > > > > > >> >> >long diff = System.currentTimeMillis() - start;
> > > > > > >> >> >System.out.println("creating connection with pool took: " + diff
> > > > > > + "
> > > > > > >> >> >milise$
> > > > > > >> >> ></snip>
> > > > > > >> >> >
> > > > > > >> >> >And got surprisingly results like this:
> > > > > > >> >> >
> > > > > > >> >> >creating connection without pool took: 465 miliseconds
> > > > > > >> >> >creating connection with pool took: 585 miliseconds
> > > > > > >> >> >
> > > > > > >> >> >In my tests the connection pool is always slower, so what did I
> > > > > > do
> > > > > > >> >> wrong?
> > > > > > >> >> >I guess this Parameter is responsible for holding active
> > > > > > Connections
> > > > > > >> in
> > > > > > >> >> >the Pool:
> > > > > > >> >> ><parameter>
> > > > > > >> >> > <name>initialSize</name>
> > > > > > >> >> > <value>20</value>
> > > > > > >> >> ></parameter>
> > > > > > >> >> >So there shold be active Connections before the getConnection( )
> > > > > > is
> > > > > > >> >> >called .. Any ideas?
> > > > > > >> >> >Regards, Henrik
> > > > > > >> >> >
> > > > > > >> >>
> > > > > > >>
> > > > > > >---------------------------------------------------------------------
> > > > > > >> >> >To unsubscribe, e-mail:
> > > > > > tomcat-user-unsubscribe@jakarta.apache.org
> > > > > > >> >> >For additional commands, e-mail:
> > > > > > tomcat-user-help@jakarta.apache.org
> > > > > > >> >>
> > > > > > >> >>
> > > > > > >> >>
> > > > > > >> >>
> > > > > > >> >> This e-mail, including any attachments, is a confidential business
> > > > > > >> >communication, and may contain information that is confidential,
> > > > > > >> >proprietary and/or privileged. This e-mail is intended only for the
> > > > > > >> >individual(s) to whom it is addressed, and may not be saved, copied,
> > > > > > >> >printed, disclosed or used by anyone else. If you are not the(an)
> > > > > > >> intended
> > > > > > >> >recipient, please immediately delete this e-mail from your computer
> > > > > > >> system
> > > > > > >> >and notify the sender. Thank you.
> > > > > > >> >>
> > > > > > >> >>
> > > > > > >> >>
> > > > > > ---------------------------------------------------------------------
> > > > > > >> >> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > > > > >> >> For additional commands, e-mail:
> > > > > > tomcat-user-help@jakarta.apache.org
> > > > > > >> >>
> > > > > > >> >
> > > > > > >>
> > > > > > >---------------------------------------------------------------------
> > > > > > >> >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > > > > >> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> This e-mail, including any attachments, is a confidential business
> > > > > > >communication, and may contain information that is confidential,
> > > > > > >proprietary and/or privileged. This e-mail is intended only for the
> > > > > > >individual(s) to whom it is addressed, and may not be saved, copied,
> > > > > > >printed, disclosed or used by anyone else. If you are not the(an)
> > > > > > intended
> > > > > > >recipient, please immediately delete this e-mail from your computer
> > > > > > system
> > > > > > >and notify the sender. Thank you.
> > > > > > >>
> > > > > > >>
> > > > > > >> ---------------------------------------------------------------------
> > > > > > >> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > > > > >> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > > > > > >>
> > > > > > >
> > > > > > >---------------------------------------------------------------------
> > > > > > >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > > > > >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> >
> >
> > > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: DBCP Performance -> solved.
Posted by Peter Lin <wo...@gmail.com>.
it's an easy mistake to make. the usual trick to benchmark and
performance testing is to prime the server a bit. we've all made
that mistake at some point.
peter
On Fri, 10 Sep 2004 19:35:43 +0200, Henrik Rathje <hr...@ki.tng.de> wrote:
> Hi,
> i did not change any settings, no restart and no anything; but now the timings are:
> 67 miliseconds pool
> 956 miliseconds nopool.
> seems it simply takes several minutes until the pool is ready to use.
> sorry for asking those stupid questions + thanks for helping,
> Henrik
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org