Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Interesting XML-DIST-APP thread
 On Wednesday 09 January 2002 08:07 pm, Tim Bray wrote: > 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. I apologize too.. I was probably a little too quick to respond. > 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. It depends on the kind of application, but yes, I have seen the use of XML-RPC cause a *considerable* slowdown over straight binary RPC. Again, the most recent case of this was the media asset management system I alluded to, which is essentially a metadata wrapper over a content store using a relational database for property storage. I would bet that if you went to some of the stock trading companies in the US (some/many of whom are great CORBA shops... they do amazing stuff) and asked them to deploy a SOAP vs. CORBA app, you'd see a marked difference in system behaviour. Their systems, despite being in CORBA, and often fine-grained, and have very stringent performance requirements. I doubt SOAP-based system would (at least not initially) meet their needs. > >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? No. Obviously you have to weigh the different factors. My point was that you need to understand the general structure of the system, including the performance characteristics of the RPC mechanism, before working out the broad architecture. As you said, if database performance is poor, the RPC mechanism overhead will be lost in the noise. Conversely, if the database is fast, and there are very large numbers of requests, the RPC overhead might be extreme. There are some applications that require very high-speed, fine-grained, sychronous updates (stock trades for example), and I would be very surprised if deploying a SOAP-based application in those domains didn't require significant hardware and network investments. A skilled carpenter knows the difference between a hammer and a screwdriver, knows when each is approriate, and knows when to use nails vs. screws (though in a pinch, he might use a screw as a nail ;-)). The same should be true of porgrammers. > 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. Yes. I know your skill in programming, and appreciate it. I'm similar, but I try to do "the simplest thing that doesn't preclude me from further evolution". It usually requires at least one prototype before I understand what that is... I think experience can help you make the right choices earlier on, so again, knowledge of all aspects of the system are useful. > >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. Well, I remember well the period from 1993-1996 or so when people were having all kind of problems with HTTP. It required a lot of software development, and a lot of network tuning, before people really figured out how to make it work well. The degredation now is an effect of that work, not the deign of HTTP per se. > 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; This is SO important, and SO true. I suffered through this in a system a built many years ago. The initial design used S-expressions over sockets as a form of extensible RPC (not unlike SOAP). The system worked great until we started talking to machines across the pacific. We eventually settled on a design that offloaded most of the work onto the client. In fact, it was a peer-to-peer system for the most part, where peers sychronized with one another based on a QOS metric. Some machines acted as servers because of their speed, and because they were weighted in the QOS so that they were always updated. > Amen. And I would further claim that we have no idea where the > real bottlenecks are going to turn out to be. Agreed here... the systems now, and the interactions between them, are complex enough that often even simulations, let alone intuitions, aren't accurate any more. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
