Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
