>You've configured a separate pool for connectors on ports 80 and 443. Why?
I thought it was better this way... Normally, the port 80 should automatically
redirect to the port 443 and https only should be authorized. Is there any
proper way to do that?
>You've reduced the acceptCount to 50. Why?
Oow ... I don't know ... tests. Do you suggest to raise it to a bigger value,
such 200 or more?
>You are compressing compressed images. Why?
Compressing compressed images? Isn't compression="off" disabling that?
>You are setting acceptorThreadCount=4. Why?
Just test :) in the documentation it's written that 2 is a good number, but we
can raise it to test, so did I and as it doesn't change anything, I left it. Do
you suggest to put back 2?
>Does your app have a database connection pool?
Yes, but directly managed by the application with MyBatis.
>What are the sizing parameters for this pool?
<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>
But apparently, the database should not be the issue, as it runs on a separate
server and when I check it, it never reaches that limits.
---
>I will assume that you're not using APR/Native based on your SSL Connection
>configuration. If you are using tcnative.dll, then the configuration for your
>SSL connector will not work.
I'm quite a newbie in tomcat tuning. That config came from an old application
(tomcat 5) that uses the same SSL certificate, and apparently, it's working...
> You've defined one Executor for each Connector. This is the default Tomcat
> behavior, so I don't see where adding and using an Executor per Connector is
> buying you anything.
> In general, using an Executor pool allows you to share threads among several
> Tomcat components. It's a nice way of managing resources and minimizing some
> overhead.
> acceptorThreadCount is set to 4. From the documentation, there doesn't seem
> to be a need to set this above 2.
> acceptCount is set to 50 (down from the default of 100). This means that the
> total possible number of connections in your configuration is 1400 (2 x 650 +
> 2 x 50). Any more requests will be refused. I'm not sure why you've reduced
> the queue size.
As you suggest, I will set back the first to 2 and the second to more than 100.
I cannot say why it's less than the default behavior. Maybe because of some
tests, or the old tomcat 5 config...
> 1. Remove the Executors
> 2. Set the Connector elements back to their factory settings
> 3. add acceptorThreadCount="2" since you have a multi-core CPU
> 4. add SSL configuration pertaining to your environment
> 5. you may want to add URIEncoding="UTF-8" depending on your web app
Ok, I'll do that.
> Then, attach VisualVM on the local machine to profile. VisualVM running
> remotely for profiling doesn't work too well.
That's already the case :)
> Finally, use a separate machine (preferably Linux) to run JMeter.
That's also already the case, but a Windows 7 one. I will launch my next tests
on a linux computer as you suggest.
> Since you mentioned oracle.net.ns.Packet.receive(), I suspect that you're
> using an Oracle database, and your web application is database - intensive.
> As Pid has mentioned, how do you manage your database connections?
Everything is on top of this mail :-)
> Once you have isolated and addressed your application performance issues, you
> can then start looking at Tomcat parameters to improve performance.
> . . . . just my two cents.
Every help is good to take, and thanks to all of you :-) I make the changes,
re-run the tests and let you know the results.
Romain.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
