Re: An idea: Apache Object Adaptor

[dthompson characterlink net (Darrin Thompson)]

On 12/18/00, 11:28:05 AM, Michael Poole <poole troilus org> wrote regarding 
Re: An idea: Apache Object Adaptor:


> You're overlooking a few very important problems in the approach of
> running CORBA over HTTP, and your analysis shows many signs of sloppy
> buzzword-inspired thinking about scalability.

I know it's sketchy but I don't think it's THAT bad. :-) And my 
inspiration didn't come from buzzwords. (ok, sorry I mentioned XML. That 
would be kind of stupid now that I think about it.) :-) My inspiration is 
a data driven apps for which this approach seems well suited. 

> First, you ignore the overhead of going through HTTP rather than a
> more CORBA-oriented protocol (like IIOP).  On the client, it's not
> that hard and it doesn't matter that much, but on the server, having
> Apache dispatch the requests properly makes for a big CPU cycle hit,
> and for real scalability you don't want to over-burden the server.

Hmmmmm. My experiences with Apache modules have shown that if a request 
doesn't need to access a file on the filesystem, Apache can handle it 
with extreme efficiency. But see below, I'll define what scalability 
means to me more clearly.

> Second, you don't really define scalability well.  I assume you mean
> scalability to handle a reasonable number of potentially interacting
> requests from many different clients (rather than scalability to
> handle many linear requests from one client quickly).

You are right, I don't. My needs usually involve both of the above. A 
small number of clients that hit the server hard and a large number of 
clients that are gentler on the server. My performance "requirement" is 
that handling of all requests begin in reasonably short period of time.

So, yes it's true that Apache will dispatch a request slower than 
straight IIOP. But I believe the difference is measured in hundreds of 
microseconds. For a data driven application (using Oracle etc.) this 
difference is orders of maginitude lower than delays introduced by 
Apache's dispatching.

> Why does the definition of scalability matter?  Because the truly hard
> part of scaling a server to many clients (and you can ask Oracle and
> Microsoft and IBM's SQL server teams about this) isn't so much in
> talking to all the clients -- how you do that efficiently is mostly a
> function of the OS and its primitives for that.  The truly hard part
> of scaling a server is making it concurrent, so that you can have
> several requests being processed at the same time.  For this, no
> performance-killing hack to add software layers will help; the server
> must be written so that it does intellilgent locking.  And for this,
> CGI scripts are very bad; there are no widely portable IPC locking
> mechanisms available besides the problematic sysv ones, and those are
> generally not very fast.

This is an excellent point. In a data driven app, however, a fully 
featured RDMS provides a lot of help here.

> (Depending on the operations, having a single-threaded server might
> give more throughput or even lower latency than a badly done
> multi-threaded server, because the multi-threaded server tends to get
> in its own way.)

But I only write well done multi-threaded servers. :-)

I my experience, I can never beat the speed and fairness of a pool of 
threads pulling requests from a queue. There are small latencies 
introduced by the pool, but it's nearly impossible for one request to 
starve the other requests. I always get real crisp response from this 
approach. 

> Third, keeping state when the server runs as a CGI script costs much
> more than just session-tracking.  If your server isn't long-lived, you
> have to read data every time the server starts, and write the data back
> before it stops.

Again you are right. However, CGI is only one way that a request could be 
handled. Apache offers CGI (slowest), Mod_Perl (very very much faster), 
native modules (speed limited by Apache only).

> So what does trying to run CORBA over HTTP win you?

> * Buzzword compliance (hey, maybe this makes you happy)

Well, no it doesn't........

> * HTTP processing overhead (particularly on the server, where the cost
>   matters the most)

> * Concurrency headaches (worse than they need to be)

> * Longer state recovery and recording times

HTTP processing overhead is very small. If this approach is only applied 
to RDMS and "data heavy" apps, the last to concerns are already expected 
and aren't all that hard to manage at all.

Darrin