You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Romain Van der Keilen <Ro...@uniway.be> on 2012/10/17 08:59:32 UTC
asking advice for tomcat 7 config
Hi There,
I'm quiet new to this mailing list as I encounter some configuration problems with Tomcat 7.0.30.
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.
Tomcat is running with the following options: jdk 1.7.0_07 ; server\jvm.dll ; initial memory pool 1024Mb ; maximum memory pool 1250 Mb ; Thread stack size : 1024 kb ; 64 bit version for both java and tomcat
The server itself is a Windows Server 2008 Standard edition running on Intel Xeon X5660 @ 2.8Ghz (2 physical processors ; 24 virtual processors ) ; 12Gb Ram
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.
I also took a look at the CPU usage in java classes, and there I saw that 95% of the time goes to org.apache.tomcat.util.threads.TaskQueue.take(). 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.
Thanks in advance,
Romain Van der Keilen.
<?xml version='1.0' encoding='utf-8'?>
<Server port="8885" shutdown="SHUTDOWN">
<!--APR library loader. Documentation at /docs/apr.html -->
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
<Listener className="org.apache.catalina.core.JasperListener" />
<!-- Prevent memory leaks due to use of particular java/javax APIs-->
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html -->
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<Service name="Catalina">
<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" >
</Connector>
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
<Host name="10.10.10.10" appBase="D:\Tomcat7\" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="D:\Logfiles\Tomcat\http\Prod" prefix="access_log." suffix=".txt" pattern="common"/>
<Context path="" docBase=" Prod" reloadable="true" crossContext="false"></Context>
</Host>
</Engine>
</Service>
</Server>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by Mark Eggers <it...@yahoo.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by Mark Thomas <ma...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: asking advice for tomcat 7 config
Posted by Romain Van der Keilen <Ro...@uniway.be>.
>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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by Mark Thomas <ma...@apache.org>.
On 17/10/2012 11:36, André Warnier wrote:
> Mark Thomas wrote:
>> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Connector_Comparison
> Thanks.
> Yes, I saw that table, but it is may be a bit "summarised" for the
> average Tomcat user (or sysadmin). Is there somewhere a more
> global/in-depth explanation of how this stuff all works ?
> (request processing, thread allocation/deallocation etc., other than
> snippets here and there related to the various connector attributes or
> the source code comments ?)
Not really. Like a lot of the Tomcat docs there is some assumed
knowledge. In this case it is assumed that the reader understands the
key differences between blocking and non-blocking IO, knows what polling
is and what it all means for thread usage.
I'm planning on talking about it at ApacheCon EU in a few weeks in my
Tomcat and reverse proxies talk since to get the configuration right and
avoid thread exhaustion you need to understand how all the moving parts
use threads. I'll put the slides up in the usual place [1] once I have
written them.
Mark
[1] http://people.apache.org/~markt/presentations/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by André Warnier <aw...@ice-sa.com>.
Mark Thomas wrote:
> On 17/10/2012 11:02, André Warnier wrote:
>> Mark Thomas wrote:
>>> On 17/10/2012 10:49, André Warnier wrote:
>>>> 1) So it means that if a client connects to the server, but does not
>>>> send any request line for a while on that connection, the server will
>>>> allocate a thread to serve the request; this thread will wait up to 20 s
>>>> (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the
>>>> pool of available threads.
>>>> Of course only a malicious client would do that..
>>> Nope. This is the NIO connector. The request line is read using
>>> non-blocking IO. The (simulated) blocking IO only starts once the first
>>> header is received and continues until the entire request is received.
>>> It then goes back to non-blocking for the next request line.
>>>
>>>
>>>> 2) it also means that a perfectly non-malicious client can connect to
>>>> the server, and send a first request on the connection; the server will
>>>> allocate a thread to handle this request; and then, if the same client
>>>> has no more requests to send for a while, this thread will nevertheless
>>>> remain waiting on this connection for 20 s. (HTTP) or 60 s. (HTTPS),
>>>> just in case the client /would/ send another request on it.
>>>> During this time, the thread is unavailable to process other client
>>>> requests.
>>> Again, nope. The thread is released between the requests.
>>>
>> Sorry, I stand corrected, I missed the NIO part.
>>
>> For the record, is the above correct for the standard BIO connector
>> (and in part for the APR connector) ?
>
> BIO yes, the above is correct.
>
> NIO is actually non-blocker for the request headers as well.
>
> APR is is non-blocking between requests.
>
> See the summary chart at [1] for more.
>
> Mark
>
> [1]
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Connector_Comparison
>
Thanks.
Yes, I saw that table, but it is may be a bit "summarised" for the average Tomcat user (or
sysadmin). Is there somewhere a more global/in-depth explanation of how this stuff all
works ?
(request processing, thread allocation/deallocation etc., other than snippets here and
there related to the various connector attributes or the source code comments ?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by Mark Thomas <ma...@apache.org>.
On 17/10/2012 11:02, André Warnier wrote:
> Mark Thomas wrote:
>> On 17/10/2012 10:49, André Warnier wrote:
>>> 1) So it means that if a client connects to the server, but does not
>>> send any request line for a while on that connection, the server will
>>> allocate a thread to serve the request; this thread will wait up to 20 s
>>> (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the
>>> pool of available threads.
>>> Of course only a malicious client would do that..
>>
>> Nope. This is the NIO connector. The request line is read using
>> non-blocking IO. The (simulated) blocking IO only starts once the first
>> header is received and continues until the entire request is received.
>> It then goes back to non-blocking for the next request line.
>>
>>
>>> 2) it also means that a perfectly non-malicious client can connect to
>>> the server, and send a first request on the connection; the server will
>>> allocate a thread to handle this request; and then, if the same client
>>> has no more requests to send for a while, this thread will nevertheless
>>> remain waiting on this connection for 20 s. (HTTP) or 60 s. (HTTPS),
>>> just in case the client /would/ send another request on it.
>>> During this time, the thread is unavailable to process other client
>>> requests.
>>
>> Again, nope. The thread is released between the requests.
>>
>
> Sorry, I stand corrected, I missed the NIO part.
>
> For the record, is the above correct for the standard BIO connector
> (and in part for the APR connector) ?
BIO yes, the above is correct.
NIO is actually non-blocker for the request headers as well.
APR is is non-blocking between requests.
See the summary chart at [1] for more.
Mark
[1]
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Connector_Comparison
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by André Warnier <aw...@ice-sa.com>.
Mark Thomas wrote:
> On 17/10/2012 10:49, André Warnier wrote:
>> 1) So it means that if a client connects to the server, but does not
>> send any request line for a while on that connection, the server will
>> allocate a thread to serve the request; this thread will wait up to 20 s
>> (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the
>> pool of available threads.
>> Of course only a malicious client would do that..
>
> Nope. This is the NIO connector. The request line is read using
> non-blocking IO. The (simulated) blocking IO only starts once the first
> header is received and continues until the entire request is received.
> It then goes back to non-blocking for the next request line.
>
>
>> 2) it also means that a perfectly non-malicious client can connect to
>> the server, and send a first request on the connection; the server will
>> allocate a thread to handle this request; and then, if the same client
>> has no more requests to send for a while, this thread will nevertheless
>> remain waiting on this connection for 20 s. (HTTP) or 60 s. (HTTPS),
>> just in case the client /would/ send another request on it.
>> During this time, the thread is unavailable to process other client
>> requests.
>
> Again, nope. The thread is released between the requests.
>
Sorry, I stand corrected, I missed the NIO part.
For the record, is the above correct for the standard BIO connector (and in part for the
APR connector) ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by Mark Thomas <ma...@apache.org>.
On 17/10/2012 10:49, André Warnier wrote:
> 1) So it means that if a client connects to the server, but does not
> send any request line for a while on that connection, the server will
> allocate a thread to serve the request; this thread will wait up to 20 s
> (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the
> pool of available threads.
> Of course only a malicious client would do that..
Nope. This is the NIO connector. The request line is read using
non-blocking IO. The (simulated) blocking IO only starts once the first
header is received and continues until the entire request is received.
It then goes back to non-blocking for the next request line.
> 2) it also means that a perfectly non-malicious client can connect to
> the server, and send a first request on the connection; the server will
> allocate a thread to handle this request; and then, if the same client
> has no more requests to send for a while, this thread will nevertheless
> remain waiting on this connection for 20 s. (HTTP) or 60 s. (HTTPS),
> just in case the client /would/ send another request on it.
> During this time, the thread is unavailable to process other client
> requests.
Again, nope. The thread is released between the requests.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by Daniel Barcellos <da...@gmail.com>.
Ok guys, apologies for my inconvenience. I was just wondering if there was
a way to solve a few problems that I'm facing here like threads that
get stuck and no way to release them.
I already chat with my client's architechs in order to ask them if they are
closing any output source when downloading things from my app.
Well I will wait when those thread problems come bach and see if I can
catch some thread dumps and stuffs...
Thanks!
2012/10/18 André Warnier <aw...@ice-sa.com>
> Christopher Schultz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Daniel,
>>
>> On 10/18/12 10:12 AM, Daniel Barcellos wrote:
>>
>>> ok... thanks for nothing...
>>>
>>
>> No thanks for the snarkiness. :(
>>
>> Pid's advice is actually good, even if you don't want to hear it:
>>
>> 2012/10/18 Pid <pi...@pidster.com>
>>>
>>> It's probably not your connector config that's the problem, if
>>>> there is one. Most of the time it's your app.
>>>>
>>>> Use a profiler, monitor JMX (use VisualVM with the MBeans plugin)
>>>> and understand what's happening rather than assuming someone
>>>> else's connector config is "good" or "better".
>>>>
>>>
>> Taking someone else's configuration doesn't really help you. Instead,
>> it makes you feel good that it improved someone else's situation and
>> therefore is likely to benefit you.
>>
>> Maybe Romain has a 64-way blade server with 32GiB of heap space: he
>> can afford a lot of threads, etc. Maybe you have a 1GiB dual-core CPU
>> and his configuration will make your environment royally suck. If you
>> want advice, ask for it. But don't just say "oh, hey, your
>> configuration worked great for you so give it to me and it will
>> certainly work great".
>>
>> Start a new thread when you've tried this & have questions.
>>>>
>>>
>> +1
>>
>> Technically, Daniel, you're hijacking Romain's thread.
>>
>>
>
> +, Daniel :
>
> Think of it this way : if there was a combination of settings that worked
> in all cases, then what would be the point of these adjustable parameters ?
> The Tomcat guys would just set them all to the optimal value, and there
> would be no need for a lot of the code and the documentation.
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: asking advice for tomcat 7 config
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Daniel,
>
> On 10/18/12 10:12 AM, Daniel Barcellos wrote:
>> ok... thanks for nothing...
>
> No thanks for the snarkiness. :(
>
> Pid's advice is actually good, even if you don't want to hear it:
>
>> 2012/10/18 Pid <pi...@pidster.com>
>>
>>> It's probably not your connector config that's the problem, if
>>> there is one. Most of the time it's your app.
>>>
>>> Use a profiler, monitor JMX (use VisualVM with the MBeans plugin)
>>> and understand what's happening rather than assuming someone
>>> else's connector config is "good" or "better".
>
> Taking someone else's configuration doesn't really help you. Instead,
> it makes you feel good that it improved someone else's situation and
> therefore is likely to benefit you.
>
> Maybe Romain has a 64-way blade server with 32GiB of heap space: he
> can afford a lot of threads, etc. Maybe you have a 1GiB dual-core CPU
> and his configuration will make your environment royally suck. If you
> want advice, ask for it. But don't just say "oh, hey, your
> configuration worked great for you so give it to me and it will
> certainly work great".
>
>>> Start a new thread when you've tried this & have questions.
>
> +1
>
> Technically, Daniel, you're hijacking Romain's thread.
>
+, Daniel :
Think of it this way : if there was a combination of settings that worked in all cases,
then what would be the point of these adjustable parameters ?
The Tomcat guys would just set them all to the optimal value, and there would be no need
for a lot of the code and the documentation.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel,
On 10/18/12 10:12 AM, Daniel Barcellos wrote:
> ok... thanks for nothing...
No thanks for the snarkiness. :(
Pid's advice is actually good, even if you don't want to hear it:
> 2012/10/18 Pid <pi...@pidster.com>
>
>> It's probably not your connector config that's the problem, if
>> there is one. Most of the time it's your app.
>>
>> Use a profiler, monitor JMX (use VisualVM with the MBeans plugin)
>> and understand what's happening rather than assuming someone
>> else's connector config is "good" or "better".
Taking someone else's configuration doesn't really help you. Instead,
it makes you feel good that it improved someone else's situation and
therefore is likely to benefit you.
Maybe Romain has a 64-way blade server with 32GiB of heap space: he
can afford a lot of threads, etc. Maybe you have a 1GiB dual-core CPU
and his configuration will make your environment royally suck. If you
want advice, ask for it. But don't just say "oh, hey, your
configuration worked great for you so give it to me and it will
certainly work great".
>> Start a new thread when you've tried this & have questions.
+1
Technically, Daniel, you're hijacking Romain's thread.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlCAFnUACgkQ9CaO5/Lv0PDpkwCgvMnJKQbrRJtKe9380RtDCOBR
E5sAn3P171y2P6CHcTm92ruFQgNaMtH+
=JT0G
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by Daniel Barcellos <da...@gmail.com>.
ok... thanks for nothing...
2012/10/18 Pid <pi...@pidster.com>
> On 18/10/2012 12:22, Daniel Barcellos wrote:
> > Hey
> >
> > I'm facing similar problems too and I guess with a good configuration of
> my server.xml would be a good start point.
> >
> > So could kindly share a good Connector configuration in this mail
> thread? What would that be the best choice in terms of max min threads keep
> alived timeout configurations ?
>
> It's probably not your connector config that's the problem, if there is
> one. Most of the time it's your app.
>
> Use a profiler, monitor JMX (use VisualVM with the MBeans plugin) and
> understand what's happening rather than assuming someone else's
> connector config is "good" or "better".
>
> Start a new thread when you've tried this & have questions.
>
>
> p
>
>
> > Thanks in advance!
> >
> > Sent from my iPhone
> >
> > On 18/10/2012, at 07:05, Romain Van der Keilen <
> Romain.VanderKeilen@uniway.be> wrote:
> >
> >> Hi there!
> >>
> >> Some news for you about my problem.
> >> I did all the modifications you suggested, it increased the response
> time a little bit (2-3 seconds better on a 15 seconds scale). It was
> already good to take, and helped me to create a healthy configuration.
> >> 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).
> >>
> >> So I think my problems are solved, thanks to you guys!
> >>
> >> Many thanks for the advices,
> >>
> >> Romain.
> >>
> >> -----Original Message-----
> >> From: André Warnier [mailto:aw@ice-sa.com]
> >> Sent: mercredi 17 octobre 2012 11:49
> >> To: Tomcat Users List
> >> Subject: Re: asking advice for tomcat 7 config
> >>
> >> Pid wrote:
> >> ...
> >>
> >>>>
> >>>> <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" >
> >>>> </Connector>
> >>>
> >>> You've configured a separate pool for connectors on ports 80 and 443.
> Why?
> >>>
> >>> You've reduced the acceptCount to 50. Why?
> >>>
> >>> You are compressing compressed images. Why?
> >>
> >> There is : compression="off" in both connectors though.
> >> So I guess that compressableMimeType should be ignored.
> >>
> >> (It /is/ still questionable to have changed the default of
> compressableMimeType, to include types which are inherently compressed
> already.)
> >>
> >>>
> >>> You are setting acceptorThreadCount=4. Why?
> >>>
> >>>
> >>> Does your app have a database connection pool?
> >>> What are the sizing parameters for this pool?
> >>>
> >>>
> >> Also,
> >>
> >> - for the HTTP connector, connectionTimeout is set to 20000
> (milliseconds), and keepAliveTimeout is not set.
> >> - for the HTTPS connector, neither one is set.
> >> That will cause :
> >> - for the HTTP connector :
> >> - connectionTimeout = 20000 ms (20 s.)
> >> - keepAliveTimeout = 20000 ms
> >> - for the HTTPS connector :
> >> - connectionTimeout = 60000 ms (60 s.)
> >> - keepAliveTimeout = 60000 ms
> >>
> >> 1) So it means that if a client connects to the server, but does not
> send any request line for a while on that connection, the server will
> allocate a thread to serve the request; this thread will wait up to 20 s
> (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the pool
> of available threads.
> >> Of course only a malicious client would do that..
> >>
> >> 2) it also means that a perfectly non-malicious client can connect to
> the server, and send a first request on the connection; the server will
> allocate a thread to handle this request; and then, if the same client has
> no more requests to send for a while, this thread will nevertheless remain
> waiting on this connection for 20 s. (HTTP) or 60 s.
> >> (HTTPS), just in case the client /would/ send another request on it.
> >> During this time, the thread is unavailable to process other client
> requests.
> >>
> >> Discarding item (1) for now as being a DOS attack, might (2) not go a
> long way to explain the symtoms that the OP is mentioning ?
> >>
> >> I would try setting :
> >> - for the HTTP connector :
> >> - connectionTimeout = 5000 ms (5 s.)
> >> - keepAliveTimeout = 5000 ms
> >> - for the HTTPS connector :
> >> - connectionTimeout = 5000 ms (5 s.)
> >> - keepAliveTimeout = 5000 ms
> >>
> >> on the premises that :
> >> - a genuine well-intentioned client is very unlikely to establish a
> connection with a webserver, and then not send any request on that
> connection for all of 5 seconds
> >> - if a client, after making a first request and having obtained the
> response to it, is then not making any further request to the server on the
> same connection for more than 5 seconds, it probably means that he has for
> now nothing more to request. And it is not the overhead of establishing a
> new TCP connection later that is nowadays going to penalise the client or
> the server.
> >> And this would allow these Tomcat threads to be recycled much faster,
> instead of just sitting there doing nothing.
> >>
> >> Is that analysis wrong ?
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
> --
>
> [key:62590808]
>
>
Re: asking advice for tomcat 7 config
Posted by Pid <pi...@pidster.com>.
On 18/10/2012 12:22, Daniel Barcellos wrote:
> Hey
>
> I'm facing similar problems too and I guess with a good configuration of my server.xml would be a good start point.
>
> So could kindly share a good Connector configuration in this mail thread? What would that be the best choice in terms of max min threads keep alived timeout configurations ?
It's probably not your connector config that's the problem, if there is
one. Most of the time it's your app.
Use a profiler, monitor JMX (use VisualVM with the MBeans plugin) and
understand what's happening rather than assuming someone else's
connector config is "good" or "better".
Start a new thread when you've tried this & have questions.
p
> Thanks in advance!
>
> Sent from my iPhone
>
> On 18/10/2012, at 07:05, Romain Van der Keilen <Ro...@uniway.be> wrote:
>
>> Hi there!
>>
>> Some news for you about my problem.
>> I did all the modifications you suggested, it increased the response time a little bit (2-3 seconds better on a 15 seconds scale). It was already good to take, and helped me to create a healthy configuration.
>> 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).
>>
>> So I think my problems are solved, thanks to you guys!
>>
>> Many thanks for the advices,
>>
>> Romain.
>>
>> -----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Sent: mercredi 17 octobre 2012 11:49
>> To: Tomcat Users List
>> Subject: Re: asking advice for tomcat 7 config
>>
>> Pid wrote:
>> ...
>>
>>>>
>>>> <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" >
>>>> </Connector>
>>>
>>> You've configured a separate pool for connectors on ports 80 and 443. Why?
>>>
>>> You've reduced the acceptCount to 50. Why?
>>>
>>> You are compressing compressed images. Why?
>>
>> There is : compression="off" in both connectors though.
>> So I guess that compressableMimeType should be ignored.
>>
>> (It /is/ still questionable to have changed the default of compressableMimeType, to include types which are inherently compressed already.)
>>
>>>
>>> You are setting acceptorThreadCount=4. Why?
>>>
>>>
>>> Does your app have a database connection pool?
>>> What are the sizing parameters for this pool?
>>>
>>>
>> Also,
>>
>> - for the HTTP connector, connectionTimeout is set to 20000 (milliseconds), and keepAliveTimeout is not set.
>> - for the HTTPS connector, neither one is set.
>> That will cause :
>> - for the HTTP connector :
>> - connectionTimeout = 20000 ms (20 s.)
>> - keepAliveTimeout = 20000 ms
>> - for the HTTPS connector :
>> - connectionTimeout = 60000 ms (60 s.)
>> - keepAliveTimeout = 60000 ms
>>
>> 1) So it means that if a client connects to the server, but does not send any request line for a while on that connection, the server will allocate a thread to serve the request; this thread will wait up to 20 s (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the pool of available threads.
>> Of course only a malicious client would do that..
>>
>> 2) it also means that a perfectly non-malicious client can connect to the server, and send a first request on the connection; the server will allocate a thread to handle this request; and then, if the same client has no more requests to send for a while, this thread will nevertheless remain waiting on this connection for 20 s. (HTTP) or 60 s.
>> (HTTPS), just in case the client /would/ send another request on it.
>> During this time, the thread is unavailable to process other client requests.
>>
>> Discarding item (1) for now as being a DOS attack, might (2) not go a long way to explain the symtoms that the OP is mentioning ?
>>
>> I would try setting :
>> - for the HTTP connector :
>> - connectionTimeout = 5000 ms (5 s.)
>> - keepAliveTimeout = 5000 ms
>> - for the HTTPS connector :
>> - connectionTimeout = 5000 ms (5 s.)
>> - keepAliveTimeout = 5000 ms
>>
>> on the premises that :
>> - a genuine well-intentioned client is very unlikely to establish a connection with a webserver, and then not send any request on that connection for all of 5 seconds
>> - if a client, after making a first request and having obtained the response to it, is then not making any further request to the server on the same connection for more than 5 seconds, it probably means that he has for now nothing more to request. And it is not the overhead of establishing a new TCP connection later that is nowadays going to penalise the client or the server.
>> And this would allow these Tomcat threads to be recycled much faster, instead of just sitting there doing nothing.
>>
>> Is that analysis wrong ?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
[key:62590808]
Re: asking advice for tomcat 7 config
Posted by Daniel Barcellos <da...@gmail.com>.
Hey
I'm facing similar problems too and I guess with a good configuration of my server.xml would be a good start point.
So could kindly share a good Connector configuration in this mail thread? What would that be the best choice in terms of max min threads keep alived timeout configurations ?
Thanks in advance!
Sent from my iPhone
On 18/10/2012, at 07:05, Romain Van der Keilen <Ro...@uniway.be> wrote:
> Hi there!
>
> Some news for you about my problem.
> I did all the modifications you suggested, it increased the response time a little bit (2-3 seconds better on a 15 seconds scale). It was already good to take, and helped me to create a healthy configuration.
> 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).
>
> So I think my problems are solved, thanks to you guys!
>
> Many thanks for the advices,
>
> Romain.
>
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: mercredi 17 octobre 2012 11:49
> To: Tomcat Users List
> Subject: Re: asking advice for tomcat 7 config
>
> Pid wrote:
> ...
>
>>>
>>> <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" >
>>> </Connector>
>>
>> You've configured a separate pool for connectors on ports 80 and 443. Why?
>>
>> You've reduced the acceptCount to 50. Why?
>>
>> You are compressing compressed images. Why?
>
> There is : compression="off" in both connectors though.
> So I guess that compressableMimeType should be ignored.
>
> (It /is/ still questionable to have changed the default of compressableMimeType, to include types which are inherently compressed already.)
>
>>
>> You are setting acceptorThreadCount=4. Why?
>>
>>
>> Does your app have a database connection pool?
>> What are the sizing parameters for this pool?
>>
>>
> Also,
>
> - for the HTTP connector, connectionTimeout is set to 20000 (milliseconds), and keepAliveTimeout is not set.
> - for the HTTPS connector, neither one is set.
> That will cause :
> - for the HTTP connector :
> - connectionTimeout = 20000 ms (20 s.)
> - keepAliveTimeout = 20000 ms
> - for the HTTPS connector :
> - connectionTimeout = 60000 ms (60 s.)
> - keepAliveTimeout = 60000 ms
>
> 1) So it means that if a client connects to the server, but does not send any request line for a while on that connection, the server will allocate a thread to serve the request; this thread will wait up to 20 s (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the pool of available threads.
> Of course only a malicious client would do that..
>
> 2) it also means that a perfectly non-malicious client can connect to the server, and send a first request on the connection; the server will allocate a thread to handle this request; and then, if the same client has no more requests to send for a while, this thread will nevertheless remain waiting on this connection for 20 s. (HTTP) or 60 s.
> (HTTPS), just in case the client /would/ send another request on it.
> During this time, the thread is unavailable to process other client requests.
>
> Discarding item (1) for now as being a DOS attack, might (2) not go a long way to explain the symtoms that the OP is mentioning ?
>
> I would try setting :
> - for the HTTP connector :
> - connectionTimeout = 5000 ms (5 s.)
> - keepAliveTimeout = 5000 ms
> - for the HTTPS connector :
> - connectionTimeout = 5000 ms (5 s.)
> - keepAliveTimeout = 5000 ms
>
> on the premises that :
> - a genuine well-intentioned client is very unlikely to establish a connection with a webserver, and then not send any request on that connection for all of 5 seconds
> - if a client, after making a first request and having obtained the response to it, is then not making any further request to the server on the same connection for more than 5 seconds, it probably means that he has for now nothing more to request. And it is not the overhead of establishing a new TCP connection later that is nowadays going to penalise the client or the server.
> And this would allow these Tomcat threads to be recycled much faster, instead of just sitting there doing nothing.
>
> Is that analysis wrong ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by André Warnier <aw...@ice-sa.com>.
Hi.
Romain Van der Keilen wrote:
> Hi there!
>
> Some news for you about my problem.
> I did all the modifications you suggested, it increased the response time a little bit (2-3 seconds better on a 15 seconds scale). It was already good to take, and helped me to create a healthy configuration.
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 ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by Pid <pi...@pidster.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
[key:62590808]
RE: asking advice for tomcat 7 config
Posted by Romain Van der Keilen <Ro...@uniway.be>.
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.
Re: asking advice for tomcat 7 config
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Romain,
On 10/18/12 6:05 AM, Romain Van der Keilen wrote:
> 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?
The obvious one being the size of the connection pool: if you are try
to test 70 simultaneous db-related operations but your connection pool
only contains 50 connections, then many of the requests are going to
sit idly-waiting for db connections. Basically, you cannot scale
beyond 50 simultaneous HTTP connections if all your requests are
db-related.
The equation looks something like this (where 'R' is the number of
HTTP requests, 'P' is the size of your connection pool and 'L' is the
proportion of all request you expect to require a db connection):
max(R) = P / L
So, if you have 50 connections in your pool and you expect 50% of your
requests to require a database connection, then you can only expect to
be able to serve 50 / 0.5 = 100 simultaneous HTTP connections.
Conversely, if you want to be able to handle 500 connections at 50%
rate, then you need to have 250 connections available in your database
pool. Of course, if you have multiple servers, then you have to be
aware that each app instance will open 250 connections to your
database. If you can't handle N*250 on the database side, then you
have to do the equation from the resource-limited side instead of from
the demand-I-want-to-serve side.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlCAFWIACgkQ9CaO5/Lv0PDKZACgmocnQvpoGVKSS4x2GcwWE9e6
kLEAn2YgbZrpQ0HqrgIiC1s5s2GanNbQ
=Kasu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: asking advice for tomcat 7 config
Posted by Romain Van der Keilen <Ro...@uniway.be>.
Hi there!
Some news for you about my problem.
I did all the modifications you suggested, it increased the response time a little bit (2-3 seconds better on a 15 seconds scale). It was already good to take, and helped me to create a healthy configuration.
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).
So I think my problems are solved, thanks to you guys!
Many thanks for the advices,
Romain.
-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com]
Sent: mercredi 17 octobre 2012 11:49
To: Tomcat Users List
Subject: Re: asking advice for tomcat 7 config
Pid wrote:
...
>>
>> <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" >
>> </Connector>
>
> You've configured a separate pool for connectors on ports 80 and 443. Why?
>
> You've reduced the acceptCount to 50. Why?
>
> You are compressing compressed images. Why?
There is : compression="off" in both connectors though.
So I guess that compressableMimeType should be ignored.
(It /is/ still questionable to have changed the default of compressableMimeType, to include types which are inherently compressed already.)
>
> You are setting acceptorThreadCount=4. Why?
>
>
> Does your app have a database connection pool?
> What are the sizing parameters for this pool?
>
>
Also,
- for the HTTP connector, connectionTimeout is set to 20000 (milliseconds), and keepAliveTimeout is not set.
- for the HTTPS connector, neither one is set.
That will cause :
- for the HTTP connector :
- connectionTimeout = 20000 ms (20 s.)
- keepAliveTimeout = 20000 ms
- for the HTTPS connector :
- connectionTimeout = 60000 ms (60 s.)
- keepAliveTimeout = 60000 ms
1) So it means that if a client connects to the server, but does not send any request line for a while on that connection, the server will allocate a thread to serve the request; this thread will wait up to 20 s (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the pool of available threads.
Of course only a malicious client would do that..
2) it also means that a perfectly non-malicious client can connect to the server, and send a first request on the connection; the server will allocate a thread to handle this request; and then, if the same client has no more requests to send for a while, this thread will nevertheless remain waiting on this connection for 20 s. (HTTP) or 60 s.
(HTTPS), just in case the client /would/ send another request on it.
During this time, the thread is unavailable to process other client requests.
Discarding item (1) for now as being a DOS attack, might (2) not go a long way to explain the symtoms that the OP is mentioning ?
I would try setting :
- for the HTTP connector :
- connectionTimeout = 5000 ms (5 s.)
- keepAliveTimeout = 5000 ms
- for the HTTPS connector :
- connectionTimeout = 5000 ms (5 s.)
- keepAliveTimeout = 5000 ms
on the premises that :
- a genuine well-intentioned client is very unlikely to establish a connection with a webserver, and then not send any request on that connection for all of 5 seconds
- if a client, after making a first request and having obtained the response to it, is then not making any further request to the server on the same connection for more than 5 seconds, it probably means that he has for now nothing more to request. And it is not the overhead of establishing a new TCP connection later that is nowadays going to penalise the client or the server.
And this would allow these Tomcat threads to be recycled much faster, instead of just sitting there doing nothing.
Is that analysis wrong ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by André Warnier <aw...@ice-sa.com>.
Pid wrote:
...
>>
>> <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" >
>> </Connector>
>
> You've configured a separate pool for connectors on ports 80 and 443. Why?
>
> You've reduced the acceptCount to 50. Why?
>
> You are compressing compressed images. Why?
There is : compression="off" in both connectors though.
So I guess that compressableMimeType should be ignored.
(It /is/ still questionable to have changed the default of compressableMimeType, to
include types which are inherently compressed already.)
>
> You are setting acceptorThreadCount=4. Why?
>
>
> Does your app have a database connection pool?
> What are the sizing parameters for this pool?
>
>
Also,
- for the HTTP connector, connectionTimeout is set to 20000 (milliseconds), and
keepAliveTimeout is not set.
- for the HTTPS connector, neither one is set.
That will cause :
- for the HTTP connector :
- connectionTimeout = 20000 ms (20 s.)
- keepAliveTimeout = 20000 ms
- for the HTTPS connector :
- connectionTimeout = 60000 ms (60 s.)
- keepAliveTimeout = 60000 ms
1) So it means that if a client connects to the server, but does not send any request line
for a while on that connection, the server will allocate a thread to serve the request;
this thread will wait up to 20 s (on HTTP) or 60 s. (on HTTPS), before timing out and
returning to the pool of available threads.
Of course only a malicious client would do that..
2) it also means that a perfectly non-malicious client can connect to the server, and send
a first request on the connection; the server will allocate a thread to handle this
request; and then, if the same client has no more requests to send for a while, this
thread will nevertheless remain waiting on this connection for 20 s. (HTTP) or 60 s.
(HTTPS), just in case the client /would/ send another request on it.
During this time, the thread is unavailable to process other client requests.
Discarding item (1) for now as being a DOS attack, might (2) not go a long way to explain
the symtoms that the OP is mentioning ?
I would try setting :
- for the HTTP connector :
- connectionTimeout = 5000 ms (5 s.)
- keepAliveTimeout = 5000 ms
- for the HTTPS connector :
- connectionTimeout = 5000 ms (5 s.)
- keepAliveTimeout = 5000 ms
on the premises that :
- a genuine well-intentioned client is very unlikely to establish a connection with a
webserver, and then not send any request on that connection for all of 5 seconds
- if a client, after making a first request and having obtained the response to it, is
then not making any further request to the server on the same connection for more than 5
seconds, it probably means that he has for now nothing more to request. And it is not the
overhead of establishing a new TCP connection later that is nowadays going to penalise the
client or the server.
And this would allow these Tomcat threads to be recycled much faster, instead of just
sitting there doing nothing.
Is that analysis wrong ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: asking advice for tomcat 7 config
Posted by Pid <pi...@pidster.com>.
On 17/10/2012 08: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.
> 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.
>
> Tomcat is running with the following options: jdk 1.7.0_07 ; server\jvm.dll ; initial memory pool 1024Mb ; maximum memory pool 1250 Mb ; Thread stack size : 1024 kb ; 64 bit version for both java and tomcat
> The server itself is a Windows Server 2008 Standard edition running on Intel Xeon X5660 @ 2.8Ghz (2 physical processors ; 24 virtual processors ) ; 12Gb Ram
>
> 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.
> I also took a look at the CPU usage in java classes, and there I saw that 95% of the time goes to org.apache.tomcat.util.threads.TaskQueue.take(). 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.
>
> Thanks in advance,
>
> Romain Van der Keilen.
>
>
> <?xml version='1.0' encoding='utf-8'?>
> <Server port="8885" shutdown="SHUTDOWN">
>
> <!--APR library loader. Documentation at /docs/apr.html -->
> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
> <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
> <Listener className="org.apache.catalina.core.JasperListener" />
> <!-- Prevent memory leaks due to use of particular java/javax APIs-->
> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
> <!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html -->
> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>
> <GlobalNamingResources>
> <Resource name="UserDatabase" auth="Container"
> type="org.apache.catalina.UserDatabase"
> description="User database that can be updated and saved"
> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> pathname="conf/tomcat-users.xml" />
> </GlobalNamingResources>
>
> <Service name="Catalina">
>
> <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" >
> </Connector>
You've configured a separate pool for connectors on ports 80 and 443. Why?
You've reduced the acceptCount to 50. Why?
You are compressing compressed images. Why?
You are setting acceptorThreadCount=4. Why?
Does your app have a database connection pool?
What are the sizing parameters for this pool?
p
> <Engine name="Catalina" defaultHost="localhost">
>
> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
>
> <Host name="10.10.10.10" appBase="D:\Tomcat7\" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="D:\Logfiles\Tomcat\http\Prod" prefix="access_log." suffix=".txt" pattern="common"/>
> <Context path="" docBase=" Prod" reloadable="true" crossContext="false"></Context>
> </Host>
>
> </Engine>
> </Service>
> </Server>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
[key:62590808]
Re: asking advice for tomcat 7 config
Posted by Daniel Barcellos <da...@gmail.com>.
I have faced similar issues as well! I have quite similar tomcat6 over a similar hardware infrastructure and sometimes we noticed some unavailable issues as well!
I already tried tuning tomcat but not success! The only thing I did last time was increase the maxthread from 200 to 500 and another tip I got here was for to take some thread dumps.
Did you already do that?
Tks
Sent from my iPhone
On 17/10/2012, at 03:59, Romain Van der Keilen <Ro...@uniway.be> wrote:
> Hi There,
>
> I'm quiet new to this mailing list as I encounter some configuration problems with Tomcat 7.0.30.
> 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.
>
> Tomcat is running with the following options: jdk 1.7.0_07 ; server\jvm.dll ; initial memory pool 1024Mb ; maximum memory pool 1250 Mb ; Thread stack size : 1024 kb ; 64 bit version for both java and tomcat
> The server itself is a Windows Server 2008 Standard edition running on Intel Xeon X5660 @ 2.8Ghz (2 physical processors ; 24 virtual processors ) ; 12Gb Ram
>
> 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.
> I also took a look at the CPU usage in java classes, and there I saw that 95% of the time goes to org.apache.tomcat.util.threads.TaskQueue.take(). 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.
>
> Thanks in advance,
>
> Romain Van der Keilen.
>
>
> <?xml version='1.0' encoding='utf-8'?>
> <Server port="8885" shutdown="SHUTDOWN">
>
> <!--APR library loader. Documentation at /docs/apr.html -->
> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
> <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
> <Listener className="org.apache.catalina.core.JasperListener" />
> <!-- Prevent memory leaks due to use of particular java/javax APIs-->
> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
> <!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html -->
> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>
> <GlobalNamingResources>
> <Resource name="UserDatabase" auth="Container"
> type="org.apache.catalina.UserDatabase"
> description="User database that can be updated and saved"
> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> pathname="conf/tomcat-users.xml" />
> </GlobalNamingResources>
>
> <Service name="Catalina">
>
> <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" >
> </Connector>
>
> <Engine name="Catalina" defaultHost="localhost">
>
> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
>
> <Host name="10.10.10.10" appBase="D:\Tomcat7\" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="D:\Logfiles\Tomcat\http\Prod" prefix="access_log." suffix=".txt" pattern="common"/>
> <Context path="" docBase=" Prod" reloadable="true" crossContext="false"></Context>
> </Host>
>
> </Engine>
> </Service>
> </Server>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org