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.
Keep in mind that Axis has not reached the point of performance
tuning yet. While it is a worthy goal to be performant, it is
the first priority to be correct.
There can be a large number of reasons for latencies. Do keep
in mind that SAX addresses scalability more than it addresses
"quickness". Sometimes the two go hand in hand. This time, we
are processing the request and responce in chuncks. That allows
Axis to process several requests at once--even if they work on
large data sets.
Now, to address latencies, Axis does have a more complex pipeline.
I am not familiar with SoapRMI or Apache SOAP internals, but I do
know that Axis has a transport pipeline and a service pipeline. The
Transport pipeline takes care of converting the incoming request to
SAX, and any other associated tasks with the transport (like
obtaining the client certificate). Axis then processes the request
and maps it to the service in question. The service has its own
pipeline--which can process SOAP Headers and modify the content coming
in. Then the service does its actual work. Lastly, we reverse the
process coming out.
All of these stages can introduce latencies. Not to mention, using
the stock serializers can introduce latencies if you are required
to pass an entire structure to it. It will naturally take longer
to process returning a large String value via SOAP if we require
the whole thing to be sent at once.
If the String serializer can accept chunks (which I suspect is what
SoapRMI is doing) then the Serializer can start the SOAP response
almost immediately. The String serializer would be sending
characters( char[], int begin, int length ) messages for each chunk
it sends.
>
>
> 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.
>
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
