[ome-devel] xml-rpc implementation evaluation

[Harry Hochheiser]

After much prodding from Ilya, and much foot-draggging on my part, I've 
conducted a comparison of XML_RPC implementations.  This evaluation was 
motivated by a feeling that SOAP::LIte was slowing things down, and 
that an alternative implementations might speed up data retrieval for 
remote clients.

PUNCH LINE:  SOAP::Lite does seem indeed seem to be slowing things 
down, with server-side overhead of .8-1 seconds, as opposed to ~ .1 
seconds (per call) for an alternative. We should revise the remote 
server and test it with an alternative implementation, based on the 
Frontier-RPC-0.1.07b4 package.


DETAILS:

There are (to my knowledge) three available libraries for doing XML-RPC 
in Perl:

	- Soap::Lite (www.soaplite.com): version 0.55 is currently what we're 
using.
	- Frontier-RPC-0.1.07b4 (http://bitsko.slc.ut.us/~ken/xml-rpc/)
	- RPC::XML 0.57 (http://www.blackperl.com/RPC::XML/)

To compare these three, I built a sandbox with distinct Apache spaces 
for each implementation. I then attempted to customize them to support 
customized serialization of responses. This is necessary for the 
optimized queries (such as the chain query) that I implemented. Since 
this query (and similar queries) creates its own XML-RPC response on 
the fly, the servers need to be able to identify such responses and 
return them unchanged. All other responses should be encoded in XML.

It turns out that this is easy to do in Soap::Lite and Frontier-RPC, 
and hard to do in RPC::XML. It turns out that RPC::XML is fairly 
painful to modify, for reasons that I won't describe in detail here 
(contact me if you're interested). For this reason, I eliminated 
RPC::XML from further consideration.

I then ran a comparison between Soap::Lite and Frontier-RPC. I tried 
three types of queries with each library:
1) a simple query requesting the sum of two integers
2) a second simple query that returned an array containing the two 
arguments passed into it.
3) a mock chain retrieval request: Instead of reading the chains from 
the database, this call reads 450K of XML containing chain execution 
data from a file and returns it, appropriately marked so that it will 
not be reserialized, and will be returned unchanged.

Each query was executed 3 times, using a null client (curl with output 
to /dev/null), against a server on my local machine. /usr/bin/time was 
used to measure the clock time required to execute each request.

Times for each server library were collected and averaged. this is a 
bit of a cheat, but it's the easiest way to show and display the data. 
Patterns are similar when looking at results for each request type.

Results are given in the graph below. "User Time" is the overall time 
of execution, as reported by /usr/bin/time. "Network Time" is the 
difference between "user time" and the complete time spent on the 
server. "Print" is the time required to send the response (once 
encoded). "Full request" is the time required to parse the request, 
identify the method, call it, and encode the results (if necessary). 
Since the methods definitions were the same in both cases - and their 
time was identical - this time is essentially the library overhead.

 From the graph, it can be seen that Frontier is a big win over 
Soap::Lite. The library overhead in Soap::Lite was almost 10x that of 
Frontier.  Frontier is also _much_ simpler.

This simplicity is not without a cost. Frontier will not do SOAP as 
well as XML::RPC. However, we do not currently do anything with SOAP. 
In order to keep this path open, I will see about  using the frontier 
library in a way that does not preclude the use of SOAP::Lite.  This 
will probably require having two parallel location directives in the 
Apache config: perhaps /Shoola and /ShoolaSoap, or something like that.

Questions/comments/feedback appreciated.

-harry
-------------- next part --------------
Skipped content of type multipart/appledouble-------------- next part --------------