Re: Proposal draft for Tomcat 5.0 : #3 Straw Man

["Christopher K. St. John" <ck...@distributopia.com>]

costinm@covalent.net wrote:
> 
> If you can clarify your concerns - do you disagree with Coyote
> entirely ( and why ), is it something missing that you want
> added or something that is there and you feel shouldn't ?
> 

 Fair enough. I think part of the problem is that one
of the primary goals of the proposal appears to be to 
find common ground between the Tomcat 3 and Tomcat 4 
camps. I have the sneaking suspicion that the code should
be the primary concern.

 A straw-man proposal might help to clarify my worries.
(it's not a real proposal, I'm looking to be told what
my incorrect assumptions are)

 From the standpoint of supporting the 2.4 spec (totally
ignoring the 3/4 thing), it seems like this might make
more sense:

 - A represenative set of benchmarks is agreed upon,
   in advance, and tests are run to determine what
   Tomcat 4 performance is like now, where the
   bottlenecks are (based on profiling, not intuition),
   and performance goals are set for Tomcat 5. What
   needs to be faster? Static file serving? HelloWorld?
   JSP's? How much faster? Exactly? etc, etc.

 - The most ugly bits of Tomcat 4 are listed, and a
   subset of them is set aside to be fixed. I've chosen
   the startup code and tomcat events/listeners as my
   biggest concerns for this straw-man, but I'm sure
   there are others. It's mainly the process of choosing
   actual, concrete problems (instead of generalities)
   that I think it important.

 - Tomcat 5 is Tomcat 4 with lots of cleanup work and
   modifications for whatever the 2.4 spec comes up
   with. There are no major architectural changes. OTOH,
   the 2.4 spec could be bizarre, in which case all bets
   are off :-)

 - Coyote is not part of Tomcat 5. Instead, Tomcat 5
   moves to having 2 (and only 2) connectors that are
   single-purpose no-compromise performance demons:

     - A special-purpose HTTP connector built to take
       full advantage of Tomcat 4, with a few layers
       of abstraction as possible, using the existing
       o.a.c.Connector API. This results in the smallest,
       fasted code possible. 

     - A special-purpose AJP connector. Again, single
       purpose, build for Tomcat 5 only, using the 
       existing o.a.c.Connector API, and again,this
       results in the least possible amount of code.

 - Other connectors can be implement in j-t-c as 
   needed, maybe as Coyote. Experiments like JNI, etc
   shouldn't be a consideration for the core Tomcat 5
   design. There should probably also be some work
   with the NIO api's non-blocking stuff, ala what
   Greg Wilkins has done with Jetty, but again this
   is non-core.

 - Tomcat 5 cleans up the current startup spaghetti
   by going through each and every Tomcat event listener
   and deciding if it needs to be made into a real,
   explicitly called API. Listeners should be hooks
   for extensions, making them them implement core
   functionality makes for a tangled mass of pointers
   and a very confusing startup sequence. Pretty much
   everything but the management listeners need to go.

   After most of the listeners are removed, the set
   of Tomcat events is rationalized and documented.
   This is a big deal. This code is an undocumented
   mess.

 - There are places where the Standard* classes make
   ugly assumptions about one another. This needs to
   be examined on a case-by-case basis, and most of
   the really ugly stuff needs to be removed, or the
   assumptions need to be made into real method calls
   in the top-level interfaces.

 - Other stuff, but since this is a straw man only,
   I think you get the idea.


-- 
Christopher St. John cks@distributopia.com
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Proposal draft for Tomcat 5.0 : #3 Straw Man

[Remy Maucherat <re...@apache.org>]

Christopher K. St. John wrote:
> costinm@covalent.net wrote:
> 
>>If you can clarify your concerns - do you disagree with Coyote
>>entirely ( and why ), is it something missing that you want
>>added or something that is there and you feel shouldn't ?
>>
> 
> 
>  Fair enough. I think part of the problem is that one
> of the primary goals of the proposal appears to be to 
> find common ground between the Tomcat 3 and Tomcat 4 
> camps. I have the sneaking suspicion that the code should
> be the primary concern.
> 
>  A straw-man proposal might help to clarify my worries.
> (it's not a real proposal, I'm looking to be told what
> my incorrect assumptions are)
> 
>  From the standpoint of supporting the 2.4 spec (totally
> ignoring the 3/4 thing), it seems like this might make
> more sense:
> 
>  - A represenative set of benchmarks is agreed upon,
>    in advance, and tests are run to determine what
>    Tomcat 4 performance is like now, where the
>    bottlenecks are (based on profiling, not intuition),
>    and performance goals are set for Tomcat 5. What
>    needs to be faster? Static file serving? HelloWorld?
>    JSP's? How much faster? Exactly? etc, etc.

I suggest you do them, and convince yourself. It is not my buisness 
trying to justify what should be evident just by reading the code.
The Coyote adapters use lazy evaluations and GC efficient objects to 
achieve better performance.

>  - The most ugly bits of Tomcat 4 are listed, and a
>    subset of them is set aside to be fixed. I've chosen
>    the startup code and tomcat events/listeners as my
>    biggest concerns for this straw-man, but I'm sure
>    there are others. It's mainly the process of choosing
>    actual, concrete problems (instead of generalities)
>    that I think it important.

The startup code (scripts, Bootstrap and Catalina classes) will still be 
present for compatibility.

BTW, maybe you consider all that ugly, but I don't. I find the XML 
Mapper / Digester pretty cool when you really think about it, and would 
really hate to see them go away.

-1.

>  - Tomcat 5 is Tomcat 4 with lots of cleanup work and
>    modifications for whatever the 2.4 spec comes up
>    with. There are no major architectural changes. OTOH,
>    the 2.4 spec could be bizarre, in which case all bets
>    are off :-)

My proposal is not very different from that.

>  - Coyote is not part of Tomcat 5. Instead, Tomcat 5
>    moves to having 2 (and only 2) connectors that are
>    single-purpose no-compromise performance demons:
> 
>      - A special-purpose HTTP connector built to take
>        full advantage of Tomcat 4, with a few layers
>        of abstraction as possible, using the existing
>        o.a.c.Connector API. This results in the smallest,
>        fasted code possible. 
> 
>      - A special-purpose AJP connector. Again, single
>        purpose, build for Tomcat 5 only, using the 
>        existing o.a.c.Connector API, and again,this
>        results in the least possible amount of code.

-1. I did it already, it doesn't work.

>  - Other connectors can be implement in j-t-c as 
>    needed, maybe as Coyote. Experiments like JNI, etc
>    shouldn't be a consideration for the core Tomcat 5
>    design. There should probably also be some work
>    with the NIO api's non-blocking stuff, ala what
>    Greg Wilkins has done with Jetty, but again this
>    is non-core.

I don't care about what you define as the core. If it has to be the 
servlet container implementation for you, then so be it.

I personally define the core as exactly the Coyote API.

- Jetty defines the core as the HTTP implementation.
- You could write a NIO based HTTP connector for Coyote.
- JK 2 with JNI is only experimental as the moment, and is not part of 
the core. It is a protocol handler which plugs into the core.

The proposal is what we call the new core be a modified version of the 
Coyote API (package org.apache.coyote, not including any subpackages). 
Then, there's the servlet container running on top of it (Catalina), and 
the protocol handlers running below it (HTTP/1.1, AJP, JNI, hopefully WARP).

Then, we proobably need some new loader code to startup the whole thing 
(that's hopefully going to be provided by commons-daemon).

>  - Tomcat 5 cleans up the current startup spaghetti
>    by going through each and every Tomcat event listener
>    and deciding if it needs to be made into a real,
>    explicitly called API. Listeners should be hooks
>    for extensions, making them them implement core
>    functionality makes for a tangled mass of pointers
>    and a very confusing startup sequence. Pretty much
>    everything but the management listeners need to go.
> 
>    After most of the listeners are removed, the set
>    of Tomcat events is rationalized and documented.
>    This is a big deal. This code is an undocumented
>    mess.

Strong -1 for actually changing the Catalina API. Rewriting the modules 
yet again is the biggest mistake we can possibly make.

>  - There are places where the Standard* classes make
>    ugly assumptions about one another. This needs to
>    be examined on a case-by-case basis, and most of
>    the really ugly stuff needs to be removed, or the
>    assumptions need to be made into real method calls
>    in the top-level interfaces.

At best, it's a small implementation detail. As long as it doesn't break 
the API too badly, I'm in favor of doing that, but we're not going to 
detail everything from that catagory in the proposal.

Actually, this looks to me like things which could even go in 4.1.x.

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Proposal draft for Tomcat 5.0 : #3 Straw Man

[co...@covalent.net]

On Fri, 21 Jun 2002, Remy Maucherat wrote:

> BTW, this is off-topic, but I have an OptimizeIt question: how do you 
> run it with Hotspot (on Windows) ? Everytime I tried, it crashed and/or 
> the profiling didn't work. So I've been using it with the classic VM, 
> but this obviously can change the results.
> Any trick you might know to make Hotspot work ?

Don't know - it seems to work fine on linux, and with JDK1.4.


> BTW, Strings are bad but needed IMO for security, right ?

Of course - the user will never see the low-level buffers, but only
the servlet API. 

However if a servlet doesn't call getHeaders(), there is no 
point of creating 6 headers * 2 strings/header * 2-3 objects per
string ( i.e. char[], the String, possibly more for byte->char
conversion ).

Costin 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Proposal draft for Tomcat 5.0 : #3 Straw Man

[Remy Maucherat <re...@apache.org>]

costinm@covalent.net wrote:
> On Fri, 21 Jun 2002, Christopher K.  St.  John wrote:
> 
> 
>> Fair enough. I think part of the problem is that one
>>of the primary goals of the proposal appears to be to 
>>find common ground between the Tomcat 3 and Tomcat 4 
>>camps. I have the sneaking suspicion that the code should
>>be the primary concern.
> 
> 
> I think the community is as important as the code, at least
> in Apache. 
> 
> Let me ask a question - how much time have you spent 
> benchmarking and profiling tomcat ? I can tell I spent
> few months with almost daily runs in OptimizeIt and 
> several 'ab' per day.
> 
> And I suspect Remy did the same - at least that's what
> 4.1 seems to indicate. And few other people do the 
> same - see the discussions on JNI performance as a recent 
> example.

Lol, yes, I did that a lot. I haven't done that for a while (last few 
times was when I optimized the Jasper 2 runtime), but I'll probably 
start over again to make sure there are no regressions.

I don't know any other way to improve performance ;-)

BTW, this is off-topic, but I have an OptimizeIt question: how do you 
run it with Hotspot (on Windows) ? Everytime I tried, it crashed and/or 
the profiling didn't work. So I've been using it with the classic VM, 
but this obviously can change the results.
Any trick you might know to make Hotspot work ?

> We are way beyond the point where 'intuition' was the 
> primary factor. 
> 
> If you believe o.a.c.c can be optimized - feel free
> to prove it. If your benchmarks show that coyote is slower
> than the old connector - let us know how you did that.
> 
> Performance is certainly not the only goal here, but 
> after 3 years we know that buffer management is important, 
> Strings are bad, char-byte conversions is expensive - and
> all of those must go into the core. 

Even if you manage to edge Coyote HTTP/1.1 performance, it's not going 
to be by a wide margin. Having written it for a simpler API would also 
probably make the Coyote HTTP/1.1 implementation cleaner and more 
maintainable.

BTW, Strings are bad but needed IMO for security, right ?

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Proposal draft for Tomcat 5.0 : #3 Straw Man

[co...@covalent.net]

On Fri, 21 Jun 2002, Christopher K.  St.  John wrote:

>  Fair enough. I think part of the problem is that one
> of the primary goals of the proposal appears to be to 
> find common ground between the Tomcat 3 and Tomcat 4 
> camps. I have the sneaking suspicion that the code should
> be the primary concern.

I think the community is as important as the code, at least
in Apache. 

Let me ask a question - how much time have you spent 
benchmarking and profiling tomcat ? I can tell I spent
few months with almost daily runs in OptimizeIt and 
several 'ab' per day.

And I suspect Remy did the same - at least that's what
4.1 seems to indicate. And few other people do the 
same - see the discussions on JNI performance as a recent 
example.

We are way beyond the point where 'intuition' was the 
primary factor. 

If you believe o.a.c.c can be optimized - feel free
to prove it. If your benchmarks show that coyote is slower
than the old connector - let us know how you did that.

Performance is certainly not the only goal here, but 
after 3 years we know that buffer management is important, 
Strings are bad, char-byte conversions is expensive - and
all of those must go into the core. 


Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>