Hi Guys,
> After that, I looked deeper into the database configuration, as I saw
> in the tests that non db relative actions were responding very fast
> (50ms for a 1000 users basis). I finally found an OracleDataSource in
> the Oracle Driver, which reacts far way better than the
> BasicDataSource I was using before (12s for 150 users for the basic
> data source, 1.5s for the oracle one, same test).
>I'd be interested to see the difference in configuration. I've never had
>problems with Tomcat's (really commons-dbcp's) BasicDataSource.
>Perhaps when you switched, you changed some essential configuration option?
In fact, I do not use the datasource directly in the tomcat config, but as a
Spring Bean. Maybe the difference is there.
As point of comparisons, here are the new and old configurations:
<bean id="dataSource" class="oracle.jdbc.pool.OracleDataSource"
destroy-method="close">
<property name="URL" value="${alea.cesardb.jdbc.url}" />
<property name="user" value="${alea.cesardb.jdbc.login}"/>
<property name="password" value="${alea.cesardb.jdbc.password}" />
<property name="connectionCachingEnabled" value="true" />
<property name="connectionCacheProperties">
<value>
MinLimit:5
MaxLimit:200
InitialLimit:5
ConnectionWaitTimeout:1200
InactivityTimeout:1080
ValidateConnection:true
</value>
</property>
</bean>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName" value="${alea.cesardb.jdbc.driver}"/>
<property name="url" value="${alea.cesardb.jdbc.url}"/>
<property name="username" value="${alea.cesardb.jdbc.login}"/>
<property name="password" value="${alea.cesardb.jdbc.password}"/>
<property name="initialSize" value="10" />
<property name="minIdle" value="10" />
<property name="maxIdle" value="20"/>
<property name="maxActive" value="150"/>
<property name="maxWait" value="10000"/>
<property name="validationQuery" value="select * from dual"/>
<property name="testOnBorrow" value="false"/>
<property name="testWhileIdle" value="true"/>
<property name="timeBetweenEvictionRunsMillis" value="1200000"/>
<property name="minEvictableIdleTimeMillis" value="1800000"/>
<property name="numTestsPerEvictionRun" value="5"/>
<property name="defaultAutoCommit" value="true"/>
</bean>
I did the same tests with only that bean changed, and what I saw on an excel
graphic with mean response time is speechless. I changed my test config to an
Ubuntu 12.04 with latest JMeter version and OpenJDK 7.
What I could see is that with the BasicDatasource, the load of the oracle
database was a 5-6 (for a 128VProc solaris machine), and the response time was
exponentially increasing. With the Oracle datasource, the response time is
linearly increasing and the load of the database server is at 61 when I
simulate 200 concurrent sessions.
>As previously mentioned by Mark (who is one of the Tomcat developers), I was
>wrong and the changes to timeouts and keepAlive that I recommended should not
>have made a difference, considering that you are using the NIO connector in
>your configuration.
>(My comments were only valid in the case of a BIO connector).
> Yet you seem to indicate 2-3 s. improvement over 15 s., which is about 20%.
> That is puzzling.
> Are you sure, and can you reproduce this consistently ?
In fact, those changes were not the only ones :-) I also changed the
acceptCount parameter (set it to 200), the executor configuration and the
compression parameters (I removed the compression config).
After those changes, what I also could see is that before, my JMeter graphic
result was very chaotic. Now, response time is almost a straight line in
charge, which is for me, a good sign of an healthy configuration...
Maybe it's still not perfect, but it's much more better than before ...
Romain.
