[
Lists Home |
Date Index |
Thread Index
]
On Thu, 11 Nov 2004 16:44:29 -0500, Roger L. Costello
<costello@mitre.org> wrote:
> Let us consider the process of a client sending XML to a server.
> Below I identify 3 "parts" to this process:
>
> Part 1: Client prepares the XML
>
> Part 2: Transmittal of the XML
>
> Part 3: Server processes the XML
>
> Now let us consider each part in turn, with the goal of determining
> the state-of-the-art practice for enhancing the performance of each
> part.
I have to think about this more, but it's not clear that these can be
decomposed so neatly. There is a tradeoff between the processing
utilization (which may equate to battery drain) needed to prepare the
XML and the bandwidth of the transmission channel. Expensive
compression only actually leads to shorter client-server latency if
the bandwidth is quite low and the messages highly compressible.
Likewise if you have plenty of bandwidth but CPU power or processing
time is a scarce resource, it may make sense to send extra information
(I'm thinking of Ximpleware's VTD stuff -- see
http://vtd-xml.sourceforge.net/ and
http://www.devx.com/xml/Article/22219 ) to minimize processing on the
other end.
>
> The W3C has a XML Binary Characterization (XBC) Working Group that is
> actively
> working to define a standard binary encoding for XML.
No, they are working to assess whether a standard is warranted by
developing use cases for binary encodings and a taxonomy of the
various properties that would have to be measured to assess whether a
particular binary encoding is providing a tangible benefit.
> I believe that the fruits
> of their labor will not be useable for several years.
If ever. They could decide that there is no plausible standard that
meets enough needs to make the effort worthwhile. Or the followon
working group could labor on until the heat death of the universe
trying to simultaneously optimize speed and space :-)
Hmm, you didn't mention the possibility of hardware-accelerated
processing on the server side ...
> Question: has anyone done a performance analysis of storing XML into a
> database?
Not all RDBMS are created equal with respect to XML. Something like
MySQL with no XML story is a very different beast from Oracle 10g or
SQL Server 2005 with native XML types. Likewise a native XML
database optimized to handle large static documents will offer
different performance characteristics than an NXDB optimized for
transaction processing on small documents, depending on the
application.
There are an immense number of properties of the XML, the application,
and the DB, middleware, and serialization technologies that need to be
considered. Look how many the Binary Characterization people had to
look at, and they are only concerned with parsing and transmission,
not storage and retrieval! .
I don't mean to throw cold water on your question! I hope it starts a
good discussion, but I think we need to either constrain it more to
talk about a certain class of XML instances (SOAP messages maybe?)
and technologies, or ask people to be very explicit about their
assumptions when responding.
|
