httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ics.uci.edu>
Subject Re: Apache 2 mutiple pools feature request
Date Thu, 04 Mar 1999 08:01:32 GMT
>Simpler doesn't always means faster - any custom protocol  ( including AJP )
>will need a lot of time to reach the optimizations done currently in IIOP
>( where a lot of people had a lot of fun).
>Plus the protocol is at least designed with speed in mind: byteorder
>negotiation, can be used over network or via direct calls, ORBs can
>optimized the calling path, etc.
>Sooner or later you will need authentication, encryption, etc -  all this is
>available in the corba design ( and sometimes in free implementations).

Ummm, no it isn't.  Among the things not included in the CORBA design
are streaming data transfers, polymorphic access control, and preemptive
negotiation -- figuring out what you need to do and what is available to
be done before there is something needing to be done (i.e., outside the
critical path).  Some of these were being worked on in OMG a while back,
but CORBA is already so full of stuff that it is in danger of not being
usable by any application, let alone what it was originally designed to do.

CORBA is a reasonably efficient, exceptionally generic RPC.  To see many of
the things that CORBA did wrong, look at the enhancements to ILU that were
needed to enable an HTTP-NG prototype.  And the best feature of ILU is
the flexible binding of IPC, not its speed as a generic RPC.  The only
thing that IIOP does is add a few bytes identifying the IIOP version and
specific orb/object of the destination, hardly the recipe for an efficient
application protocol, unless the application uses short control messages
over low latency connections with very little data flow.

>So I think it will be tough for a custom protocol to beat corba - many smart
>people spent lots of time designing it.

You'd be surprised how easy it is.  HTTP/1.0 beats CORBA for any operation
involving serious data transfer (>2KB payload), because HTTP doesn't have
to discover the interface before using it, doesn't have to buffer data
into smaller interactions, doesn't need to wait until the parameters are
complete before the stub returns, and doesn't have to perform data
marshalling beyond the header fields.  Any working API that is designed
for simultaneous streaming data transfer of control data, representation
data, representation metadata, resource metadata, and meta-metadata will
outperform one that requires multiple interactions to achieve the same
results, and that is before the performance tuning.  The cost of setting
up and performing an IPC interaction far exceeds anything you can get out
of tuning a working interface, unless the tuning includes avoidance of the
interaction itself (e.g., caching).

This doesn't mean CORBA is a bad thing -- it just means it wasn't designed
for distributed hypermedia.  There are hundreds of other applications for
which CORBA-like protocols are better than large-grain data transfer protocols.

....Roy

Mime
View raw message