You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/11/28 23:25:53 UTC
Non Blocking IO for Cornerstone
I am almost done with the first iteration of Non-Blocking IO for Cornerstone.
I will commit it as soon as I can get it to compile :p. That way anyone who
wants to play with it can--although it probably doesn't work.
There is one more abstraction to the whole Connection paradigm to really make
Non-Blocking IO effective. The reason is that the read/write mechanisms require
the user to know what on earth they are doing. It would almost be better to
have a higher-level block that only has the read/write/close methods available.
However, this is probable best as a JDK 1.4 only thing as I would like to take
advantage of a pool of DirectByteBuffers that further speed up communication.
If the communication is done via char arrays, byte arrays, or strings, we might
be able to provide an abstraction--but the issue remains that we still incur
a copy overhead.
Maybe we can hash it out later....
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Non Blocking IO for Cornerstone
Posted by Peter Donald <pe...@apache.org>.
On Fri, 30 Nov 2001 08:38, Jeff Turner wrote:
> On Fri, Nov 30, 2001 at 12:18:34AM +1100, Peter Donald wrote:
> [..]
>
> > Actually a while back there was some hubub because someone wrote a java
> > webserver that behaved like this and it beat the pants off all the major
> > native webservers (even those with all the fancy kernel hooks). Can't
> > remember exact details but I believe the guy was one of the people on the
> > spec for NIO and that he had already written his own non-blocking io API
> > as part of an academic project.
>
> I think you're referring to Matt Welsh's SEDA and nbio projects:
>
> http://www.cs.berkeley.edu/~mdw/proj/seda/
> "SEDA is an acryonym for staged event-driven architecture, and
> decomposes a complex, event-driven application into a set of stages
> connected by queues. This design avoids the high overhead associated
> with thread-based concurrency models, and decouples event and thread
> scheduling from application logic."
>
> http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
>
> The PDF paper on SEDA makes for good reading on the train.
yep - thats the one. Brilliant work.
Another tasty look is the ACE framework (Adaptive Communication Environment?)
which has extensive documentation on these sort of patterns. Great
documentation ... slightly overdesigned and made a few C++ specific
assumptions but great work none the less.
> Makes me wonder.. do people *want* massive concurrency? Is performance
> really an issue with current server architectures? I'm sure it is in
> some cases, but the rest..
in some cases it is vital. When you need to support massive concurency - like
I do with my simulation/game architecture then there is no real alternative.
It becomes a lot easier to support these kind of architectures when you are
dealing with a request/response architecture that has clearly defined PDUs
and so forth.
> I suspect plain old manageability and ease of use are more important.
yep - most of the time ease will win out. However with a number of our
abstraction layers (ie servlets for webpages) it could easily be implemented.
We could send and receive data from one thread and then send "events" to
ServletContainer when the full request has arrived or all data has been
flushed or whatever. That way you could minimize the amount of time that the
servlets will spend blocking on data and so forth.
> Still, it would be fun to play with.
I don't know if fun is the word to I would use to describe it - maybe
"challenging" ;)
--
Cheers,
Pete
The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten. --Jules Feiffer (cartoonist)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Non Blocking IO for Cornerstone
Posted by Berin Loritsch <bl...@apache.org>.
Jeff Turner wrote:
> On Fri, Nov 30, 2001 at 12:18:34AM +1100, Peter Donald wrote:
> [..]
>
>>Actually a while back there was some hubub because someone wrote a java
>>webserver that behaved like this and it beat the pants off all the major
>>native webservers (even those with all the fancy kernel hooks). Can't
>>remember exact details but I believe the guy was one of the people on the
>>spec for NIO and that he had already written his own non-blocking io API as
>>part of an academic project.
>>
>
> I think you're referring to Matt Welsh's SEDA and nbio projects:
>
> http://www.cs.berkeley.edu/~mdw/proj/seda/
> "SEDA is an acryonym for staged event-driven architecture, and
> decomposes a complex, event-driven application into a set of stages
> connected by queues. This design avoids the high overhead associated
> with thread-based concurrency models, and decouples event and thread
> scheduling from application logic."
>
> http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
>
> The PDF paper on SEDA makes for good reading on the train.
Thanks for the links, I will look at them in more detail later.
> Makes me wonder.. do people *want* massive concurrency? Is performance
> really an issue with current server architectures? I'm sure it is in
> some cases, but the rest.. I suspect plain old manageability and ease of
> use are more important.
Production servers want to have their cake and eat it too. They want both
manageability AND scalability. If Cornerstone/Phoenix can prove itself to
be more efficient, stable, secure, and scalable than IBM WebSphere/BEA WebLogic,
it will get people's attention. You know that the big dogs are playing with
it, and it would be really fun to see if we can create a standalone Java
based web server (think simple file-based server) that can outperform the C based
Apache HTTPD. It would totally rock!
Beyond that, it also makes it easier to sell Avalon to management, which in
turn increases the time I have to develop for it :).
> Still, it would be fun to play with.
:p
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Non Blocking IO for Cornerstone
Posted by Jeff Turner <je...@socialchange.net.au>.
On Fri, Nov 30, 2001 at 12:18:34AM +1100, Peter Donald wrote:
[..]
>
> Actually a while back there was some hubub because someone wrote a java
> webserver that behaved like this and it beat the pants off all the major
> native webservers (even those with all the fancy kernel hooks). Can't
> remember exact details but I believe the guy was one of the people on the
> spec for NIO and that he had already written his own non-blocking io API as
> part of an academic project.
I think you're referring to Matt Welsh's SEDA and nbio projects:
http://www.cs.berkeley.edu/~mdw/proj/seda/
"SEDA is an acryonym for staged event-driven architecture, and
decomposes a complex, event-driven application into a set of stages
connected by queues. This design avoids the high overhead associated
with thread-based concurrency models, and decouples event and thread
scheduling from application logic."
http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
The PDF paper on SEDA makes for good reading on the train.
Makes me wonder.. do people *want* massive concurrency? Is performance
really an issue with current server architectures? I'm sure it is in
some cases, but the rest.. I suspect plain old manageability and ease of
use are more important.
Still, it would be fun to play with.
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Non Blocking IO for Cornerstone
Posted by Peter Donald <pe...@apache.org>.
On Thu, 29 Nov 2001 09:25, Berin Loritsch wrote:
> I am almost done with the first iteration of Non-Blocking IO for
> Cornerstone. I will commit it as soon as I can get it to compile :p. That
> way anyone who wants to play with it can--although it probably doesn't
> work.
sounds interesting.
> There is one more abstraction to the whole Connection paradigm to really
> make Non-Blocking IO effective. The reason is that the read/write
> mechanisms require the user to know what on earth they are doing. It would
> almost be better to have a higher-level block that only has the
> read/write/close methods available.
the best architecture I know about is to change paradigms completely.
Currently almost all java based applications follow the single thread per
connection model. Each thread reads data from a single thread and the
operates on it and sends it back. Even non-java applications are mainly
written like this.
However this is woefully innefficient performance wise - much easier to write
code though, much much easier to verify that that code is correct and is less
buggy.
However if you want to go for real network performance it is pretty much a
given that you need to change to an event based architecture. What this means
is you usually allocate one thread per CPU to do all your processing.
This single thread does a select() on the relevent resources (ie sockets in
our case) and receives events like.
* 7 bytes received for connection 42
* 7 bytes sent on connection 2 (and thus ready to buffer to send again).
I have seen systems that were previously capable of handling 10 connections
go up to handling 130 or so using an architecture similar to this.
Actually a while back there was some hubub because someone wrote a java
webserver that behaved like this and it beat the pants off all the major
native webservers (even those with all the fancy kernel hooks). Can't
remember exact details but I believe the guy was one of the people on the
spec for NIO and that he had already written his own non-blocking io API as
part of an academic project.
Anyways great for performance but can be hell to write servers using that
architecture... its part of what I do for my "fun" stuff ... and lets just
say it is not fun .. the best it could be described as is "a good challenge"
;)
> However, this is probable best as a JDK
> 1.4 only thing as I would like to take advantage of a pool of
> DirectByteBuffers that further speed up communication. If the communication
> is done via char arrays, byte arrays, or strings, we might be able to
> provide an abstraction--but the issue remains that we still incur a copy
> overhead.
>
> Maybe we can hash it out later....
kool.
--
Cheers,
Pete
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>