You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Roy Wilson <de...@bellatlantic.net> on 2000/11/08 12:32:26 UTC
TC4-m4 REquestInfoExample data, questions, modified scripts
Hi,
I apologize for the critical tone (but also perhaps ignorance)of my last
post. I've got the flu or something. Yecch.
Here's the data I collected after running new, slightly modified, scripts
(see attached) for which RequestInfoExample is requested by ab 100,000
times on a Celeron 400Mz, 256MB SD100 memory, WD Caviar disk, Redhat6.1,
with almost nothing else going on:
C T X Conn Proc %Busy Overhead T-Overhead CPU/req
secs reqs/sec ms avg CPU CPU min secs secs
ms
1 2912.778 34.33 0 28 100 0.87 52.2 2860.578 0.0286
10 1495.122 66.88 0 149 100 0.92 55.2 1439.922 0.0144
20 1488.695 67.17 0 297 100 0.98 58.8 1429.895 0.0143
30 1503.032 66.53 0 450 100 1.12 67.2 1435.832 0.0144440 1591.704 62.83
0 636 100 1.31 78.6 1513.104 0.0151
The earlier results involving the HelloWorldExample servlet were affected
by variability which I think/hope is averaged out by the large number of
requests made.
The disk, as expected shows only about 1.8 requests per second, and is
not the bottleneck anyway (as expected).
My earlier results concerning HelloWorldExample were based on a smaller N
and were not adjusted to account for CPU overhead. I'll re-run them ASAP.
In the earlier results, thread queue locking was observed. Craig noted
that the number of background threads is set to 75 in the config file.
With that in mind, I made sure that the ab script ran with 70 or fewer
concurrent requests. Here's what happened:
catalina_log*.txt shows "HttpProcessor starting background
thread[8080][i]" where i runs from 0/1 up to 50.
catalina.out contains a full thread dump (50 on down), one of which
involves the message "Waiting to be notified HttpProcessor[8080][43]".
This appears to be the result of a segmentation violation involving
HttpProcessor[8080][50] that is also reported. Of course, ab barfs from C
= 50 onward. As I recall, SEGV was also the cause of the thread dump when
I ran HelloWorldExample. So, the thread dump seems to be a repeatable
phenomena (on my machine), apparently a function of N & C.
QUESTION 1: Does segmentation violation occur on other machines? If so,
is it a problem? If not, why not?
QUESTION 2: What do the thruput and average processing times mean? Are
they "good", "bad", or what?
QUESTION 3: Since the scripts can be modified to run any servlet, how
about a "realistic" one as Costin suggested in his ApacheCon presentation
(unless the examples are "representative").
(Hack) Roy
--
Roy Wilson
E-mail: designrw@bellatlantic.net
Re: TC4-m4 REquestInfoExample data, questions, modified scripts
Posted by sa...@totalsync.com.
> I suggest we consider not including the AccesLogValve in the default
> configuration until some optimization work is done on it.
>
I would suggest that you don't remove it from the default, as TC4 is not
even beta, and the nice access log is one of the reasons I am using it.
Scott Sanders
Re: TC4-m4 REquestInfoExample data, questions, modified scripts
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Remy Maucherat wrote:
>
> I suggest we consider not including the AccesLogValve in the default
> configuration until some optimization work is done on it.
>
For anyone who has been itching to get their feet wet and contribute to Tomcat's
development, this is the kind of thing where it's relatively easy to get
started, because you don't have to learn the entire code base (hint, hint :-).
>
> Remy
>
Craig
Re: Logging TC4.0 and measurement
Posted by Remy Maucherat <re...@apache.org>.
> Remy,
>
> I wondered about the impact of logging.
>
> I'm not personally interested in comparing 3.x and 4.x, just in getting a
> database on 4.0. I also wonder if such a comparison might ignore the
> feature differences noted in the rant postings last week.
>
> I am interested in what the thruput and response time numbers might mean
> to a user when the system is experiencing a certain load level and a
> certain mix of requests.
>
> If no comparison with TC3.x is to be made, then should the AccessLogValve
> be removed from the configuration? I think it might be good to leave it
> in to see what performance people get out of the box. If AccessLogValve
> is and continues to be a hog, then maybe it shouldn't be a default?
Unless we optimize it, I think it should be left out of the default
configuration.
> BTW, what did you use to do the profiling? What did you see? I'm planning
> to use OptimizeIt4.0 when I can get it and get it to attach.
A quick run of hprof gave me enough data on what needs the most work.
The main conclusion is that the part of the code which needs the most work
is HttpProcessor.read. All the functions which make use ot it will probably
end up being rewritten too. That code is quite old anyway and it's a planned
rewrite (but always delayed because of more important issues).
Remy
Logging TC4.0 and measurement
Posted by Roy Wilson <de...@bellatlantic.net>.
Remy,
I wondered about the impact of logging.
I'm not personally interested in comparing 3.x and 4.x, just in getting a
database on 4.0. I also wonder if such a comparison might ignore the
feature differences noted in the rant postings last week.
I am interested in what the thruput and response time numbers might mean
to a user when the system is experiencing a certain load level and a
certain mix of requests.
If no comparison with TC3.x is to be made, then should the AccessLogValve
be removed from the configuration? I think it might be good to leave it
in to see what performance people get out of the box. If AccessLogValve
is and continues to be a hog, then maybe it shouldn't be a default?
BTW, what did you use to do the profiling? What did you see? I'm planning
to use OptimizeIt4.0 when I can get it and get it to attach.
Roy
--
Roy Wilson
E-mail: designrw@bellatlantic.net
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 11/8/00, 12:21:45 PM, "Remy Maucherat" <re...@apache.org> wrote regarding
Re: TC4-m4 REquestInfoExample data, questions, modified scripts:
> TC4-m4 REquestInfoExample data, questions, modified scriptsHi,
> I did some testing myself, mainly because it's been 3 months since my
last
> round, and Catalina has changed a bit since then.
> I also did a little bit of profiling of Catalina as a whole, and of the
HTTP
> connector.
> When you do some testing, you may want to remove the AccessLogValve from
> your configuration, because it's incredibly slow right now. Also, by
> default, Catalina logs a lot of stuff, which is not the case with TC3.x,
for
> example. To get a fair comparison between 2 servers, I think the level of
> logging should be similar.
> I suggest we consider not including the AccesLogValve in the default
> configuration until some optimization work is done on it.
> Remy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC4-m4 REquestInfoExample data, questions, modified scripts
Posted by Remy Maucherat <re...@apache.org>.
TC4-m4 REquestInfoExample data, questions, modified scriptsHi,
I did some testing myself, mainly because it's been 3 months since my last
round, and Catalina has changed a bit since then.
I also did a little bit of profiling of Catalina as a whole, and of the HTTP
connector.
When you do some testing, you may want to remove the AccessLogValve from
your configuration, because it's incredibly slow right now. Also, by
default, Catalina logs a lot of stuff, which is not the case with TC3.x, for
example. To get a fair comparison between 2 servers, I think the level of
logging should be similar.
I suggest we consider not including the AccesLogValve in the default
configuration until some optimization work is done on it.
Remy
Re: TC4-m4 REquestInfoExample data, questions, modified scripts
Posted by cm...@yahoo.com.
One small note - a very important time is the "Max response time" - IMHO
it's even more important than the average response time, because it
can mean "lost customers" ( who will wait 10 secs to order from your site
:-).
HelloWorldServlet is a very bad test case, it uses Locales and that's
something very slow ( plus un-wanted disk access, etc).
It would be also interesting to measure individual servlet API calls, like
getParameter() -
that's a place where most of the tunning will probably go in tc3 at least.
Costin
>
> Here's the data I collected after running new, slightly modified, scripts
> (see attached) for which RequestInfoExample is requested by ab 100,000
> times on a Celeron 400Mz, 256MB SD100 memory, WD Caviar disk, Redhat6.1,
> with almost nothing else going on:
>
> C T X Conn Proc %Busy Overhead T-Overhead CPU/req
> secs reqs/sec ms avg CPU CPU min secs secs
> ms
>
> 1 2912.778 34.33 0 28 100 0.87 52.2 2860.578 0.0286
> 10 1495.122 66.88 0 149 100 0.92 55.2 1439.922 0.0144
> 20 1488.695 67.17 0 297 100 0.98 58.8 1429.895 0.0143
> 30 1503.032 66.53 0 450 100 1.12 67.2 1435.832 0.0144440 1591.704 62.83
> 0 636 100 1.31 78.6 1513.104 0.0151
>
> The earlier results involving the HelloWorldExample servlet were affected
> by variability which I think/hope is averaged out by the large number of
> requests made.
> The disk, as expected shows only about 1.8 requests per second, and is
> not the bottleneck anyway (as expected).
>
> My earlier results concerning HelloWorldExample were based on a smaller N
> and were not adjusted to account for CPU overhead. I'll re-run them ASAP.
>
> In the earlier results, thread queue locking was observed. Craig noted
> that the number of background threads is set to 75 in the config file.
> With that in mind, I made sure that the ab script ran with 70 or fewer
> concurrent requests. Here's what happened:
>
> catalina_log*.txt shows "HttpProcessor starting background
> thread[8080][i]" where i runs from 0/1 up to 50.
>
> catalina.out contains a full thread dump (50 on down), one of which
> involves the message "Waiting to be notified HttpProcessor[8080][43]".
> This appears to be the result of a segmentation violation involving
> HttpProcessor[8080][50] that is also reported. Of course, ab barfs from C
> = 50 onward. As I recall, SEGV was also the cause of the thread dump when
> I ran HelloWorldExample. So, the thread dump seems to be a repeatable
> phenomena (on my machine), apparently a function of N & C.
>
> QUESTION 1: Does segmentation violation occur on other machines? If so,
> is it a problem? If not, why not?
>
> QUESTION 2: What do the thruput and average processing times mean? Are
> they "good", "bad", or what?
>
> QUESTION 3: Since the scripts can be modified to run any servlet, how
> about a "realistic" one as Costin suggested in his ApacheCon presentation
> (unless the examples are "representative").
>
> (Hack) Roy
>