Re: XML Performance in a Transacation
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> > >
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