You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 2000/02/11 01:03:23 UTC
HTTP + XML + SCP = HTTP/ng
On Mon, 7 Feb 2000, Martin Pool wrote:
> Given the state of Java and HTTP today I wonder whether it would be
> better to build a toolkit of Java classes for building HTTP servers,
> rather than using AJP to plug into Apache.
that's what i was advocating.
> Where's Apache going to go in the future? Is it going to be a single
> big do-everything program, or a cluster of complementary projects?
i hope not, but unfortunately there's a little bit of momentum... i've
made a couple attempts to suggest ways we could split it up. but i don't
have the energy to evangelise the topic.
so one of the points i brought up earlier in the thread hasn't been
addressed: what problems are people trying to solve?
the web applications of which i'm aware are essentially composed of:
- static content
- dynamic content which is cacheable (i.e. almost static)
- dynamic content which is uncacheable
the best url design includes all these components under the same hostname.
so either all the services end up on one box, or some sort of front-end is
required.
both apache and squid perform as front-ends today.
if we had a front-end server with the following feature set:
- full HTTP/1.1 proxy cache
- HTTP/1.1 server capable of serving static files
- uses async i/o at least for serving static files (which includes
files in the proxy cache)
- capable of dividing the urlspace amongst different pools of
backend servers
- capable of load balancing amongst several backends within a pool
- handles persistant/pipelined connections with clients and with
backends
- SSL
in this scenario i would expect the back-ends to talk http. the front-end
would parse the incoming request and either handle it from disk/cache, or
pass it through to a back-end.
then i'd really like to know what applications can't be solved? real
world examples please, you know how much of a pain i am :)
i mean i can think of some. consider authentication. you might want your
entire urlspace to live behind an auth method which you want to implement
in java to talk to your databases in some way. but you've got portions of
your urlspace served by static files, some served by perl, and some served
by java.
well, the front-end could make a SOAP request (XML over HTTP) to your java
back-end, and presumably your java back-end can return a response which is
temporarily cacheable. the front-end keeps that in its proxy cache...
(or heck it could just proxy a HEAD request... my point is that it can
just pass the entire client request to the backend.)
anyhow we could go through each phase of the current module API and come
up with an application... but when i sit down and think about these things
i frequently find myself showing that a particular api phase just isn't
needed.
aren't the php and java back-ends just content handlers today? they don't
even touch other API phases right?
i honestly don't see the point of CORBA, or any of the other binary
protocols.
- they require more code, which clobbers L1 cache efficiency (which i'm
willing to bet will eliminate any perceived benefit you're hoping for by
making things binary)
- they require us to document the interfaces and be careful about defining
semantics... whereas HTTP/1.1 proxying is well defined by rfc2616, that
work is done for us already.
- some of us haven't had the patience to keep up with the object protocol
acronym soup of the day ;)
- most of us will end up using XML anyhow, and we've already got XML
libraries in our codebases (this is if we even need SOAP)
- code reuse #1
about the only extension to HTTP which i think we might want to consider
is Simon Spero's SCP -- session control protocol. (you can find a version
of it named TMP used without credit in rfc2371). SCP allows you to
optimise front-end/back-end communications by multiplexing multiple
streams into one tcp session... big performance boost from this.
HTTP + XML + SCP = HTTP/ng :)
other than C and java libraries implementing SCP, what's missing?
Dean
Re: HTTP + XML + SCP = HTTP/ng
Posted by Dean Gaudet <de...@arctic.org>.
On Fri, 11 Feb 2000, Jeffrey W. Baker wrote:
> Dean Gaudet wrote:
> > - full HTTP/1.1 proxy cache
> > - HTTP/1.1 server capable of serving static files
> > - uses async i/o at least for serving static files (which includes
> > files in the proxy cache)
> > - capable of dividing the urlspace amongst different pools of
> > backend servers
> > - capable of load balancing amongst several backends within a pool
> > - handles persistant/pipelined connections with clients and with
> > backends
> > - SSL
>
> If #3 above includes buffering, then I'm with you. If not, I would add
> buffering. It is very important for the front end to decouple the back
> end from the client's pipe, so as to allow the two layers to scale
> independently. I realize that one can just as easily tweak the kernel's
> socket buffer size, but I believe there are smarter ways to go about
> that.
yes i knew i forgot something :)
Dean
Re: HTTP + XML + SCP = HTTP/ng
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
Dean Gaudet wrote:
>
> On Mon, 7 Feb 2000, Martin Pool wrote:
>
> > Given the state of Java and HTTP today I wonder whether it would be
> > better to build a toolkit of Java classes for building HTTP servers,
> > rather than using AJP to plug into Apache.
>
> that's what i was advocating.
>
> > Where's Apache going to go in the future? Is it going to be a single
> > big do-everything program, or a cluster of complementary projects?
>
> i hope not, but unfortunately there's a little bit of momentum... i've
> made a couple attempts to suggest ways we could split it up. but i don't
> have the energy to evangelise the topic.
>
> so one of the points i brought up earlier in the thread hasn't been
> addressed: what problems are people trying to solve?
>
> the web applications of which i'm aware are essentially composed of:
>
> - static content
> - dynamic content which is cacheable (i.e. almost static)
> - dynamic content which is uncacheable
>
> the best url design includes all these components under the same hostname.
> so either all the services end up on one box, or some sort of front-end is
> required.
>
> both apache and squid perform as front-ends today.
>
> if we had a front-end server with the following feature set:
>
> - full HTTP/1.1 proxy cache
> - HTTP/1.1 server capable of serving static files
> - uses async i/o at least for serving static files (which includes
> files in the proxy cache)
> - capable of dividing the urlspace amongst different pools of
> backend servers
> - capable of load balancing amongst several backends within a pool
> - handles persistant/pipelined connections with clients and with
> backends
> - SSL
If #3 above includes buffering, then I'm with you. If not, I would add
buffering. It is very important for the front end to decouple the back
end from the client's pipe, so as to allow the two layers to scale
independently. I realize that one can just as easily tweak the kernel's
socket buffer size, but I believe there are smarter ways to go about
that.
The current choice of Apache or Squid for a load-balance, failing-over,
buffering, caching HTTP accellerator are unsatisfactory. In high
performance situations I find myself rolling my own. The most daunting
thing about that is of course handling the HTTP protocol itself, where I
rely on the philosophy of passing everything verbatim to the backend
Apache and doing whatever it does, which also doubles as free keep-alive
logic.
I would be very pleased to see some kind of libapachehttp for the
protocol, libapacheio for async Fu, and something very like squid's
redirector interface for implementing load balancing, failover, and
urlspace logic. SSL is a bonus that can already be lifted from openssl,
and I can personally do without caching altogether.
Context: I am much more interested in using HTTP as an application
protocol between remote clients and my application server than I am in
delivering HTML documents. The two have very different requirements in
that a pure application server generally doesn't generate anything
cachable and doesn't serve static files of any kind.
Cheers,
Jeffrey
Re: HTTP + XML + SCP = HTTP/ng
Posted by Dean Gaudet <de...@arctic.org>.
On Fri, 11 Feb 2000, Martin Pool wrote:
> JServ talked about using the W3C's MUX protocol to achieve a similar
> thing in the httpd-jvm connection. But honestly, why bother?
>
> Poluting the higher-level protocol (http) with performance workarounds
> for the lower-level protocol (tcp) seems pretty ugly. Good
> implementations of persistent connections seems more useful.
i consider SCP/MUX to be another transport layer... and in the context of
doing RPC over HTTP it's really beneficial in that it gives two packet
request/response. in many cases you get the ACK piggybacking as well
which cuts packet costs roughly in half. i don't really see this as a
fault of TCP -- TCP does its thing well, plopping SCP over it lets two
servers communicate efficiently at scale.
gotta remember this is at scale with lots of parallel streams going on.
Dean
Re: HTTP + XML + SCP = HTTP/ng
Posted by Yves Lafon <yl...@w3.org>.
On Fri, 11 Feb 2000, Martin Pool wrote:
> Certainly when I was active in JServ I think there was a feeling in
> the back of our minds that ``we shouldn't do our own http handling
> because we don't want to compete with the Apache httpd'', although of
> course there were other reasons. Most of those reasons have now gone
> away; Java is more or less stable and fast enough to write the whole
> web server in pure Java.
As of jdk1.1.6, it was possible to have the same level of performance
between a server written in Java and Apache (on Solaris), with just more
memory used ;)
> > about the only extension to HTTP which i think we might want to consider
> > is Simon Spero's SCP -- session control protocol. (you can find a version
> > of it named TMP used without credit in rfc2371). SCP allows you to
> > optimise front-end/back-end communications by multiplexing multiple
> > streams into one tcp session... big performance boost from this.
>
> JServ talked about using the W3C's MUX protocol to achieve a similar
> thing in the httpd-jvm connection. But honestly, why bother?
>
> Poluting the higher-level protocol (http) with performance workarounds
> for the lower-level protocol (tcp) seems pretty ugly. Good
> implementations of persistent connections seems more useful.
Well, if it is just between some machine you have control on, it is better
to fix the multiplexed connection at the tcp leve, if not, then you have
to use application level fixes, it is easier to ask people to upgrade
their software rather than their low level tcp stacks.
/\ - Yves Lafon - World Wide Web Consortium -
/\ / \ Architecture Domain - Jigsaw Activity Leader
/ \ \/\
/ \ / \ http://www.w3.org/People/Lafon - ylafon@w3.org
Re: HTTP + XML + SCP = HTTP/ng
Posted by Martin Pool <mb...@linuxcare.com.au>.
On Thu, Feb 10, 2000 at 04:03:23PM -0800, Dean Gaudet wrote:
> On Mon, 7 Feb 2000, Martin Pool wrote:
> > Given the state of Java and HTTP today I wonder whether it would be
> > better to build a toolkit of Java classes for building HTTP servers,
> > rather than using AJP to plug into Apache.
>
> that's what i was advocating.
Certainly when I was active in JServ I think there was a feeling in
the back of our minds that ``we shouldn't do our own http handling
because we don't want to compete with the Apache httpd'', although of
course there were other reasons. Most of those reasons have now gone
away; Java is more or less stable and fast enough to write the whole
web server in pure Java.
If we see Apache as a family of products then that concern goes away;
we can offer a configuration of JServ that talks to Apache and another
that runs standalone. Depending on other factors -- what fraction of
the site is servlets, whether they need SSL, and so on -- people can
choose one or the other.
> > Where's Apache going to go in the future? Is it going to be a single
> > big do-everything program, or a cluster of complementary projects?
>
> i hope not, but unfortunately there's a little bit of momentum... i've
> made a couple attempts to suggest ways we could split it up. but i don't
> have the energy to evangelise the topic.
From context I guess you mean you hope it won't be monolithic. In
that case I'm with you.
> so one of the points i brought up earlier in the thread hasn't been
> addressed: what problems are people trying to solve?
That's the question I'd really like to hear answered about CORBA
integration.
> aren't the php and java back-ends just content handlers today? they don't
> even touch other API phases right?
As far as I know that is true, for both of them.
> - they require more code, which clobbers L1 cache efficiency (which i'm
> willing to bet will eliminate any perceived benefit you're hoping for by
> making things binary)
The other important point is that it makes them very difficult to
audit and secure. There's a document somewhere that describes the
results of sending random data to commercial CORBA ORBs; almost all of
them fall over immediately.
> about the only extension to HTTP which i think we might want to consider
> is Simon Spero's SCP -- session control protocol. (you can find a version
> of it named TMP used without credit in rfc2371). SCP allows you to
> optimise front-end/back-end communications by multiplexing multiple
> streams into one tcp session... big performance boost from this.
JServ talked about using the W3C's MUX protocol to achieve a similar
thing in the httpd-jvm connection. But honestly, why bother?
Poluting the higher-level protocol (http) with performance workarounds
for the lower-level protocol (tcp) seems pretty ugly. Good
implementations of persistent connections seems more useful.
--
Martin Pool, Technical Support Engineer, Linuxcare, Inc.
+61 2 6262 8990
mbp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
Re: HTTP + XML + SCP = HTTP/ng
Posted by Dean Gaudet <dg...@arctic.org>.
bleh, i'm on neither, tomcat-dev@tomcat.apache.org, nor
jserv-dev@list.working-dogs.com... so if folks want those other folks
still in on this thread then could someone please forward? thanks.
Dean
On Thu, 10 Feb 2000, Dean Gaudet wrote:
> On Mon, 7 Feb 2000, Martin Pool wrote:
>
> > Given the state of Java and HTTP today I wonder whether it would be
> > better to build a toolkit of Java classes for building HTTP servers,
> > rather than using AJP to plug into Apache.
>
> that's what i was advocating.
>
> > Where's Apache going to go in the future? Is it going to be a single
> > big do-everything program, or a cluster of complementary projects?
>
> i hope not, but unfortunately there's a little bit of momentum... i've
> made a couple attempts to suggest ways we could split it up. but i don't
> have the energy to evangelise the topic.
>
> so one of the points i brought up earlier in the thread hasn't been
> addressed: what problems are people trying to solve?
>
> the web applications of which i'm aware are essentially composed of:
>
> - static content
> - dynamic content which is cacheable (i.e. almost static)
> - dynamic content which is uncacheable
>
> the best url design includes all these components under the same hostname.
> so either all the services end up on one box, or some sort of front-end is
> required.
>
> both apache and squid perform as front-ends today.
>
> if we had a front-end server with the following feature set:
>
> - full HTTP/1.1 proxy cache
> - HTTP/1.1 server capable of serving static files
> - uses async i/o at least for serving static files (which includes
> files in the proxy cache)
> - capable of dividing the urlspace amongst different pools of
> backend servers
> - capable of load balancing amongst several backends within a pool
> - handles persistant/pipelined connections with clients and with
> backends
> - SSL
>
> in this scenario i would expect the back-ends to talk http. the front-end
> would parse the incoming request and either handle it from disk/cache, or
> pass it through to a back-end.
>
> then i'd really like to know what applications can't be solved? real
> world examples please, you know how much of a pain i am :)
>
> i mean i can think of some. consider authentication. you might want your
> entire urlspace to live behind an auth method which you want to implement
> in java to talk to your databases in some way. but you've got portions of
> your urlspace served by static files, some served by perl, and some served
> by java.
>
> well, the front-end could make a SOAP request (XML over HTTP) to your java
> back-end, and presumably your java back-end can return a response which is
> temporarily cacheable. the front-end keeps that in its proxy cache...
> (or heck it could just proxy a HEAD request... my point is that it can
> just pass the entire client request to the backend.)
>
> anyhow we could go through each phase of the current module API and come
> up with an application... but when i sit down and think about these things
> i frequently find myself showing that a particular api phase just isn't
> needed.
>
> aren't the php and java back-ends just content handlers today? they don't
> even touch other API phases right?
>
> i honestly don't see the point of CORBA, or any of the other binary
> protocols.
>
> - they require more code, which clobbers L1 cache efficiency (which i'm
> willing to bet will eliminate any perceived benefit you're hoping for by
> making things binary)
>
> - they require us to document the interfaces and be careful about defining
> semantics... whereas HTTP/1.1 proxying is well defined by rfc2616, that
> work is done for us already.
>
> - some of us haven't had the patience to keep up with the object protocol
> acronym soup of the day ;)
>
> - most of us will end up using XML anyhow, and we've already got XML
> libraries in our codebases (this is if we even need SOAP)
>
> - code reuse #1
>
> about the only extension to HTTP which i think we might want to consider
> is Simon Spero's SCP -- session control protocol. (you can find a version
> of it named TMP used without credit in rfc2371). SCP allows you to
> optimise front-end/back-end communications by multiplexing multiple
> streams into one tcp session... big performance boost from this.
>
> HTTP + XML + SCP = HTTP/ng :)
>
> other than C and java libraries implementing SCP, what's missing?
>
> Dean
>
>