On 10/17/2012 1:28 AM, Mark Thomas wrote:
On 17/10/2012 07:59, Romain Van der Keilen wrote:
Hi There,
I'm quiet new to this mailing list as I encounter some configuration
problems with Tomcat 7.0.30.
It is unlikely to help but you may as well upgrade to 7.0.32.
We are currently developing a web
application, and we wish to have a good response time with about 200
parallel sessions. My problem is that starting from 70 users, the
system does not respond quietly. At 70 users, we have an average of
4000ms for the response time. At 120 users we are at an average of
20000ms and with 200 users we have about 45000ms of response time.
All of those numbers were computed with JMeter, using 4 passes.
I have seen very strange results with JMeter under load, particularly on
Windows. The results you are seeing may not be entirely correct. I get
better results (although less control) with ab on Windows. Or I run
JMeter on Linux.
When the server is under a big load, what I could see with VisualVM
is that the heap size used never exceed 500Mb. When 500Mb is reached,
it drops back to about 100Mb. Another thing is that the CPU never
works more than 5% of its capabilities.
That suggests that the app is not CPU bound.
I also took a look at the CPU
usage in java classes,
Using what>
and there I saw that 95% of the time goes to
org.apache.tomcat.util.threads.TaskQueue.take().
That is normal and means for 95% of the total thread processing time,
threads are waiting for the next task to process. It is the other 5% you
want to concentrate on.
The first class
related to my application is the oracle.net.ns.Packet.receive() and
is at 0.1% of the CPU time ...
I've looked on a lot of forums to try to tune my tomcat
configuration, but I haven't found anything that could really help
me, this is the reason I ask to you. I've just put you the whole
server.xml file after this, hoping you can have a look and tell me if
there is some big issue with it... The only thing I changed is the IP
of the server.
Profiling is the way to go to fix this and it looks like you are heading
in the right direction however you may need some better tools.
Mark
I'll fold in some of Pid's comments as well.
It's a bit late and I've not explored this particular environment
before. However, I'll attempt to make some comments based on your
configuration.
I've taken the liberty in reformatting a portion of your configuration
so I could find things more easily.
<Executor name="tomcatThreadPool"
namePrefix="catalina-exec-80-"
maxThreads="650"
minSpareThreads="100" />
<Connector executor="tomcatThreadPool"
address="10.10.10.10"
port="80"
maxHttpHeaderSize="8192"
protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="443"
server="lighthttpd/2.0.0"
enableLookups="false"
acceptorThreadCount="4"
socket.directBuffer="false"
compression="off"
compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,image/jpeg,image/png,image/gif"
acceptCount="50"
bufferSize="4096" />
<Executor name="stomcatThreadPool"
namePrefix="catalina-exec-443-"
maxThreads="650"
minSpareThreads="100" />
<Connector executor="stomcatThreadPool"
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="443"
SSLEnabled="true"
scheme="https"
secure="true"
clientAuth="false"
sslProtocol="TLS"
keystoreFile="D:\keystore\appks"
server="lighthttpd/2.0.0"
enableLookups="false"
keystorePass="changeit"
address="10.10.10.10"
acceptorThreadCount="4"
socket.directBuffer="false"
compression="off"
compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,image/jpeg,image/png,image/gif"
acceptCount="50"
bufferSize="4096" />
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.
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.
On your Connector elements, a few things stand out.
The protocol that you've chosen can accept up to 10000 requests. However
you've limited this to 650 by the use of the Executor element.
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.
I don't understand your compression configuration setup. You've set
compression to off, but then you set compressibleMineTypes? I'm also not
sure if the Connector will compress non-text MIME types even when told
to (need to look at the code). This is especially confusing for image
MIME types that are already compressed.
Finally, bufferSize does not seem to be an attribute for Tomcat 7. This
did exist in Tomcat 6.
My immediate thoughts are to do the following:
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
Then, attach VisualVM on the local machine to profile. VisualVM running
remotely for profiling doesn't work too well.
Finally, use a separate machine (preferably Linux) to run JMeter.
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?
1. Do you use connection pooling?
2. Is the connection pooling Tomcat-controlled?
3. What is the configuration
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.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
