You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Gerard van Enk <ge...@eo.nl> on 2002/02/07 23:00:28 UTC

Tomcat 4.0.1 Performance tuning problems

Hello,

We're having some troubles with our Tomcat4.0.1. I'm not sure if there's 
a problem in the configuration or if it's something else.
First the configuration:

Sun-Fire-280R/Solaris 8
1024MB Memory
Sun jdk1.3.1_01 with 512MB for the jvm

and the following configuration for the proxy-connector:

<Connector className="org.apache.catalina.connector.http.HttpConnector"
                port="8081" minProcessors="100" maxProcessors="150"
                enableLookups="false"
                acceptCount="20" debug="0" connectionTimeout="15000"
                proxyPort="80"/>

The server is getting about 300000 requests (hits) a day. A while after 
starting the server we're getting the following message:

2002-02-07 21:51:29 HttpConnector[8081] No processor available, 
rejecting this connection

It looks like the connections aren't freed after being used. But I'm not 
sure how I can test it.
Allmost every page contains database-queries, but we're using heavy 
caching (in memory and oscaches for the jsp-pages). What can I do, 
increase the maxprocessors? But how far can I go, I did some tests, but 
it looks like  more than 150 isn't possible. How many memory do I need 
per processor?

If somebody could give some hints.....

Gerard
.


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>


Re: Tomcat 4.0.1 Performance tuning problems

Posted by Gerard van Enk <ge...@eo.nl>.
Remy Maucherat wrote:
>>I tried this (not in a live-situation, but with ab), but I don't see any
>>difference. I can't reproduce the situation with ab. But it's still
>>happening in the live-server. Could it be 150 processors isn't enough in
>>our situation?
>>
> 
> Maybe. It depends on the number of simultaneous users accessing the server.
> If you go beyond what a single standalone Tomcat can provide (which is
> constrained by your OS, usually), you have to set up some load balancing
> (using JK and TC 4.0.2).
> 
> By your comments, I understand that you also get the "out of processors"
> problem with the HTTP/1.0 connector. Is that right ?
> 
> 
>>I would love the help you on this one, but I find it very hard to
>>reproduce it :(
>>
> 
> Same for me. That's why the bug is still not resolved :-(
> 
> 
>>I'll do some more testing and keep you informed.

Is there a way (besides netstat) to monitor the incoming connections? Or 
to view the status of the connectionpool?

At this moment you only get messages in your log about starting extra 
processors, but not when (if) these are being removed. Or isn't that the 
case, when the server isn't so busy the number of processors will 
decrease 'till the number of the minProcessors?


Gerard


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>


Re: Tomcat 4.0.1 Performance tuning problems

Posted by Gerard van Enk <ge...@eo.nl>.
Remy Maucherat wrote:
>>I tried this (not in a live-situation, but with ab), but I don't see any
>>difference. I can't reproduce the situation with ab. But it's still
>>happening in the live-server. Could it be 150 processors isn't enough in
>>our situation?
>>
> 
> Maybe. It depends on the number of simultaneous users accessing the server.
> If you go beyond what a single standalone Tomcat can provide (which is
> constrained by your OS, usually), you have to set up some load balancing
> (using JK and TC 4.0.2).
> 

I know. At the moment we added a lot of oscache-tags to our jsp-pages 
and increased the maxProcessors to 255. Untill now we didn't ran out of 
processors. 150 Processors for 300000 request/day were probably not enough.

> By your comments, I understand that you also get the "out of processors"
> problem with the HTTP/1.0 connector. Is that right ?
> 

Not exactly. I did some testing using ab, and both the HTTP/1.0 and 
HTTP/1.1 connector ran out of processors, but it was when using a 
maxProcessors of 150 and more than 150 simultaneous requests. And when 
ab finished the server was still running. So this is normal behaviour. I 
couldn't reproduce the situation where I got the "out off processors" 
message and the server allmost crashed as it did in the live situation.

Gerard


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>


Re: Tomcat 4.0.1 Performance tuning problems

Posted by Remy Maucherat <re...@apache.org>.
> I tried this (not in a live-situation, but with ab), but I don't see any
> difference. I can't reproduce the situation with ab. But it's still
> happening in the live-server. Could it be 150 processors isn't enough in
> our situation?

Maybe. It depends on the number of simultaneous users accessing the server.
If you go beyond what a single standalone Tomcat can provide (which is
constrained by your OS, usually), you have to set up some load balancing
(using JK and TC 4.0.2).

By your comments, I understand that you also get the "out of processors"
problem with the HTTP/1.0 connector. Is that right ?

> I would love the help you on this one, but I find it very hard to
> reproduce it :(

Same for me. That's why the bug is still not resolved :-(

> I'll do some more testing and keep you informed.

Thanks.

Remy


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>


Re: Tomcat 4.0.1 Performance tuning problems

Posted by Gerard van Enk <ge...@eo.nl>.
Remy Maucherat wrote:
>>Hello,
>>
>>We're having some troubles with our Tomcat4.0.1. I'm not sure if there's
>>a problem in the configuration or if it's something else.
>>First the configuration:
>>
>>Sun-Fire-280R/Solaris 8
>>1024MB Memory
>>Sun jdk1.3.1_01 with 512MB for the jvm
>>
>>and the following configuration for the proxy-connector:
>>
>><Connector className="org.apache.catalina.connector.http.HttpConnector"
>>                port="8081" minProcessors="100" maxProcessors="150"
>>                enableLookups="false"
>>                acceptCount="20" debug="0" connectionTimeout="15000"
>>                proxyPort="80"/>
>>
>>The server is getting about 300000 requests (hits) a day. A while after
>>starting the server we're getting the following message:
>>
>>2002-02-07 21:51:29 HttpConnector[8081] No processor available,
>>rejecting this connection
>>
>>It looks like the connections aren't freed after being used. But I'm not
>>sure how I can test it.
>>Allmost every page contains database-queries, but we're using heavy
>>caching (in memory and oscaches for the jsp-pages). What can I do,
>>increase the maxprocessors? But how far can I go, I did some tests, but
>>it looks like  more than 150 isn't possible. How many memory do I need
>>per processor?
>>
>>If somebody could give some hints.....
>>
> 
> Bug 5735 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5735) is
> currently the "most wanted" Tomcat bug. Unfortunately, it's very hard to
> debug or find in which component the bug is, so if you or anyone else can
> help, that would be great.
> 
> The bug could be either:
> - in the connector code, or in the networking code
> - in the thread pooling code (in which case the other connectors, like JK,
> could be affected since they reuse the code)
> 
> You can try the HTTP/1.0 connector (it's commented out in the default
> configuration), and see if there are still problems. If the problems are
> gone, then it's likely the cause is the first item (although I have no idea
> what it could be at this point).

I tried this (not in a live-situation, but with ab), but I don't see any 
difference. I can't reproduce the situation with ab. But it's still 
happening in the live-server. Could it be 150 processors isn't enough in 
our situation?

I would love the help you on this one, but I find it very hard to 
reproduce it :(

I'll do some more testing and keep you informed.

Gerard


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>


Re: Tomcat 4.0.1 Performance tuning problems

Posted by Remy Maucherat <re...@apache.org>.
> Hello,
>
> We're having some troubles with our Tomcat4.0.1. I'm not sure if there's
> a problem in the configuration or if it's something else.
> First the configuration:
>
> Sun-Fire-280R/Solaris 8
> 1024MB Memory
> Sun jdk1.3.1_01 with 512MB for the jvm
>
> and the following configuration for the proxy-connector:
>
> <Connector className="org.apache.catalina.connector.http.HttpConnector"
>                 port="8081" minProcessors="100" maxProcessors="150"
>                 enableLookups="false"
>                 acceptCount="20" debug="0" connectionTimeout="15000"
>                 proxyPort="80"/>
>
> The server is getting about 300000 requests (hits) a day. A while after
> starting the server we're getting the following message:
>
> 2002-02-07 21:51:29 HttpConnector[8081] No processor available,
> rejecting this connection
>
> It looks like the connections aren't freed after being used. But I'm not
> sure how I can test it.
> Allmost every page contains database-queries, but we're using heavy
> caching (in memory and oscaches for the jsp-pages). What can I do,
> increase the maxprocessors? But how far can I go, I did some tests, but
> it looks like  more than 150 isn't possible. How many memory do I need
> per processor?
>
> If somebody could give some hints.....

Bug 5735 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5735) is
currently the "most wanted" Tomcat bug. Unfortunately, it's very hard to
debug or find in which component the bug is, so if you or anyone else can
help, that would be great.

The bug could be either:
- in the connector code, or in the networking code
- in the thread pooling code (in which case the other connectors, like JK,
could be affected since they reuse the code)

You can try the HTTP/1.0 connector (it's commented out in the default
configuration), and see if there are still problems. If the problems are
gone, then it's likely the cause is the first item (although I have no idea
what it could be at this point).

Remy


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>