[
Lists Home |
Date Index |
Thread Index
]
Dave,
Without knowing the environment or the other transaction components its
impossible to say how long anything will take. You need to do some
actual measurement in your own environment using the tools that you are
using. The chances are that your XML processing costs are not
insignificant. XML processing is CPU intensive and hardly the most
machine-efficient way of handling data. Adding in validation adds
additional overhead that I would expect were proportional to the
complexity of the interaction between the XML document and the schema.
There are a few questions to address:
1. Define "transaction" - is it getting the message, parsing it,
transforming it in some fashion and storing it, or does it include the
business logic that acts on the data? If you are trying to argue that
XML is not expensive then you had better look at "whole of life" costs
for the transaction.
2. Decompose the costs - what is important/what is the problem? Elapsed
time, CPU, IO, memory? Are you running out of CPU? Elapsed time?
What? "Everything" is not a useful answer at this point. Something is
causing the question to be asked in your environment..
3. Model - what parts of the processing are there and how stable are
their costs? If you have an XML transform that takes 50ms and database
or messaging acess that takes 3000ms then you don't care about the XML.
If you have database access that takes 10ms then the XML will look bad.
This depends on what your problem is, what your platform is, and why the
question is being asked. Are all your XML documents the same size?
Size will cost you something too.
4. Measure - this is quite straight-forward. The last time I needed
this kind of number I used a JNI-based Log4J filter to get the OS CPU
time for the thread and process and externalise it. Measuring was then
a process of subtracting numbers from each other.
Now, to give you some utterly useless numbers:
I have seen XML parsing add over a hundred milliseconds to a transaction
on a Sun box, out of a total transaction cost of something like 250ms.
This was quite expensive in that environment and the XML was not large
but it was being mapped into Java objects and the time included object
construction and associated overheads. That application had other
performance problems (the remaining 150ms in the transaction). In
another environment, on an Intel box, we were happy to take 160ms each
to read, XSL transform and store XML messages in a fairly complex way
because that performance was far better than we needed.
Greg
David Carver wrote:
> This is a pretty general question, and I know that it can very from
> application to application, and even from parser to parser. However,
> I'm curious if anybody has any links to some performance tests that
> show the overall time a transaction takes to complete, and how much of
> that overall transaction time is devoted to parsing or validation of
> an XML file. Particularly, from retrieving an XML file from a data
> store, and then completing the end transaction.
>
> I've been requested to provide some numbers to show that actual XML
> validation results and parsing are a small portion of the overall
> transaction process, when dealing with XML in a B2B process. Any
> information that can be provided would be appreciated.
>
> Dave
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
|
