[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Performance in Client-Server Interactions

• To: Rich Salz <rsalz@d...>
• Subject: Re: XML Performance in Client-Server Interactions
• From: Dennis Sosnoski <dms@s...>
• Date: Fri, 12 Nov 2004 15:13:08 -0800
• Cc: "Roger L. Costello" <costello@m...>, xml-dev@l...
• In-reply-to: <4194ECD6.1000909@d...>
• References: <200411112144.iABLibA26545@s...> <4194ECD6.1000909@d...>
• User-agent: Mozilla Thunderbird 0.8 (X11/20040913)

Rich Salz wrote:

>
> One interesting things about client/server XML is that the computing 
> load is asymmetric.  It's a heck of a lot easier to generate XML than 
> it is to consume and process it.  Your note didn't seem to take that 
> into account.
>
Not sure what you're basing this on, Rich, but it doesn't match what 
I've seen. See the results at 
http://xbis.sourceforge.net/performance.html, for instance, where 
generating text XML from a parse event stream takes on average about the 
same amount of time as parsing the text to get back the parse event 
stream (ignore the first graphs, which just show a problem in the Sun 
JVM, and look at figures 4-6; for this test set parsing is somewhat 
slower than writing for larger documents, writing is considerably slower 
than parsing for smaller documents). Applications don't have to go 
through a parse event stream to generate the XML, of course, but I doubt 
that they can get a big advantage by other output techniques - the SAX 
parse event stream interface is just basically writing out XML 
components, after all. This performance parity also matches what I've 
seen with data binding approaches (see 
http://www-106.ibm.com/developerworks/library/x-databdopt2/ for examples).

If you're validating the XML against a schema that's a different story; 
validation tends to be expensive, and in my experience is not widely 
used in production systems. The overhead there would apply where ever 
you do the validation (more often on the receiving end, but can be 
either or both).

Roger, you may also be interested in my pair of devWorks articles on 
"Improving XML Transport Performance" that cover some of the same areas 
you've listed: 
http://www-106.ibm.com/developerworks/xml/library/x-trans1.html and 
http://www-106.ibm.com/developerworks/xml/library/x-trans2/

  - Dennis

-- 
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA  425.885.7197

• Follow-Ups:
  • Re: XML Performance in Client-Server Interactions
    • From: Rich Salz <rsalz@d...>
  • Re: XML Performance in Client-Server Interactions
    • From: Elliotte Harold <elharo@m...>

• References:
  • XML Performance in Client-Server Interactions
    • From: "Roger L. Costello" <costello@m...>
  • Re: XML Performance in Client-Server Interactions
    • From: Rich Salz <rsalz@d...>

• Prev by Date: Re: Excellent Insight on Standards Development vs Invention
• Next by Date: RE: Excellent Insight on Standards Development vs Invention
• Previous by thread: Re: XML Performance in Client-Server Interactions
• Next by thread: Re: XML Performance in Client-Server Interactions
• Index(es):
  • Date
  • Thread