[
Lists Home |
Date Index |
Thread Index
]
At 06:13 PM 09/01/02 -0500, Gavin Thomas Nicol wrote:
>As you wish Tim. I think this comment is content-free, and insulting to boot.
Sorry Gavin - I was irritated not at you but at the original
"dirty secret" article, and I stand by my claim that it was
effectively content-free.
> If you had cared to take
>in the point I was making, it is that naive fine-grained use of SOAP-ish
>things will result in poor performance... substantially more so than naive
>use of pure binary RPC. I have tested this, and found it to be true.
In a typical database-centric application? Wow... my experience
is different, and my intuition is that in the end, the difference
between SOAP et al, RMI, CORBA, etc, will all come out in the wash.
But I'm old enough to have little or no faith my intuition on
complicated things like that and Gavin and I are in complete
agreement that you gotta measure first.
>My point was that if you use fatter protocols, you need to take that fatness
>into account in the design...
Even before you have an idea what the general shape of the processing
workload is? Seems to me like you could end up significantly
complicating your design (e.g. toward asynchronous implementations)
only to feel bad once you discover that the thing spends all its
time down in the Oracle JOIN implementation, or the BEA cache
manager, or whatever.
My instinct has always been to build systems in the simplest
possible way (which XML message passing usually is) as fast
as possible and then once you have something working, as a side
effect you'll have an understanding of the problem you're
actually trying to solve. Sort of the Extreme Programming approach.
>As things go, HTTP is also well-known as being a pretty inefficient protocol
>overall (remember Eric Naggum;-)).
You know, I don't believe that any more. Empirically, HTTP-based
systems seem to degrade way more gracefully under load than anyone
would reasonably expect from analyzing things. The real reason the
web is slow is because of its server-centricity and the fact that
you're not allowed to do any significant processing on the client;
the same reasons that IBM mainframes and VAXes were slow back in
the eighties. In that context, the Web Services approach has the
potential of providing a major performance boost.
>As I've said in other messages, I'm not flaming web services, just noting
>that to use them well will require skills that many people today simply don't
>have... and to get good performance will take a lot more effort than people
>might think. They might appear "cool and new", but the problems, the
>solutions, and the complexities are actually pretty old.
Amen. And I would further claim that we have no idea where the
real bottlenecks are going to turn out to be. My intuition is
that the relative fatness of the messages will vanish in the
static, but I'll only be mildly surprised if I'm wrong.
I'm sure Gavin and myself could each reel off a dozen stories
of slow systems where "everybody knew" what the problem was,
and everybody was wrong. -Tim
|
