hi Dan,
thanks for your work on XML/SOAP performance and i look forward ot read your
article.
i am the author of SoapRMI/Java and wanted to add some comments. as of SoapRMI (now
called XSOAP) please mention in your article also that the updated version of XSOAP
1.3 will address some performance issues that we identified to improve: use of
optimized HTTP keep-alive and chunked encoding should greatly improve latency when
multiple method calls are considered.
as of DOM/SAX and recorded events stream: i believe that a mixed approach of
DOM/SAX/other is the best to SOAP processing however to be able to benefit most one
needs to use a progressive kind of DOM-like incremental XML tree that is built when
SOAP processor explicitly requests it (and only then).
for the optimal performance a direct access to XML stream should be allowed
(without any buffering or XML events recording) when the SOAP processor asks for
it.
moreover the SOAP processor should be able to replace parts of incrementally built
DOM-like XML tree with equivalent object representation. for example a deserialized
header can be put into SOAP envelope (represented as XML tree) and then the SOAP
envelope is passed to the next entity in pipeline.
that means that although in-memory representation is created when needed the impact
on memory usage is minimized as XML is replaced by deserialized object
representation and for well defined parts of SOAP envelope (like array or struct)
no XML DOM-like representation is ever created but XML is directly pulled/pushed by
XML parser (such as SAX2 or XPP2) into deserialized java objects.
i have implemented along those ideas an incremental XML DOM-like tree in XPP2 that
is called XmlPullNode and allows for incremental XML tree building and switching
between XML pull parsing or SAX2 parsing just for parts of tree. it works both
using my simple XML tokenizer and on top of Xerces2 XNI. for more details please
see:
http://www.extreme.indiana.edu/xgws/xsoap/xpp/
thanks,
alek
ps. i have also done quite lot of thinking about push and pull XML parsing - if you
are interested in XML performance and parsing you may want to look at my technical
report 'Design of a Pull and Push Parser System for Streaming XML'
available at http://www.extreme.indiana.edu/xgws/index.html#papers
Dan Davis wrote:
> I've been doing some simple experiements that compare AXIS,
> Apache SOAP, and other implementations (SoapRMI).
>
> One test requests a single string (size 200, 400, and 800), and
> another an array of integers (array size 200, 400, and 800).
> There's no argument to the functions (not an echo test),
> because most real-world web-apps will send small requests
> most of the time. All tests are performed on the same host to discount
> network delays. I use all default serializers/deserializers and
> SOAP encoding. The strings and arrays are pre-built on the server.
> Note this doesn't measure the throughput of the server,
> just the latency when the server is idle. There's a warming
> period for class loading and stuff.
>
> I expected to see that Axis has lower latency than
> Apache due to use of SAX, but I don't see that. Axis is
> actually slower.
>
> getInt(200) getInt(400) getInt(800)
>
> SoapRMI 22.2 ms 24.4 ms 31.5 ms
> Apache SOAP 65.8 ms 117.3 ms 190.7 ms
> Apache Axis 79.7 ms 157.4 ms 238.8 ms
>
> getStr(200) getStr(400) getStr(800)
>
> SoapRMI 19.3 ms 19.6 ms 19.9 ms
> Apache SOAP 22.7 ms 24.2 ms 25.1 ms
> Apache Axis 20.9 ms 19.6 ms 20.6 ms
>
> I'm using all default serializers, deserializers. The strings
> and arrays are pre-built and initialized on the server. SOAP
> encoding.
>
> Do you have any suggestions for speeding up Axis with
> the current code-base?
>
> This is for an article that I'll post here once complete.
