On 19/10/2012 08:43, Romain Van der Keilen wrote:
> 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">
Exactly which version of commons DBCP are you using?
That class is not one shipped with Tomcat - it's a dependency of your
application. If it's an old version, it's probably the heavily
synchronised DBCP & this might account in part for the difference in
performance.
> <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"/>
Not the same 150 != 200.
> <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).
Good plan, change a bunch of things & then compare the results...
p
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
--
[key:62590808]
signature.asc
Description: OpenPGP digital signature
