I use XML-RPC as the communications protocol between an Apache web server and a middleware piece that talks to a MySQL database. The web server contains a mixture of CGI scripts written in Python and two websites written in Mason (Apache+mod_perl). Performance is fine. Give either of these a try:
I've also implemented some middleware between Apache and SQL Server, using XMLRPC. Unfortunately, large queries were the order of the day, and things started moving like treacle. I profiled the code, and discovered that 30 seconds of the 35 second response time was being chewed up in building and parsing XML. I hacked things a bit, and instead of sending XML, sent pickles inside the XML response. This dropped response times to around the 8 second mark. This was still not good enough, as multiple queries could still choke up the system. Typical queries were about 1000-10000 records of 3-15 fields of varying datatypes, including unicode. Don't ask me why people needed these kind of reports, I'm just the programmer, and don't always get to control design decisions. :-) This demonstrates that sometimes, in real world apps, large amounts of data need to be shipped around, and it needs to happen fast. I guess when interoperability counts, XMLRPC is the best solution. When controlling both ends of the connection, pickle _should_ be best, except it is stated as being unsecure.
That's fine, so XML-RPC is slower than Gherkin. I can't run the Gherkin code, but my XML-RPC numbers are a bit different than yours:
XMLRPC encode 0.65 seconds XMLRPC decode 2.61 seconds
That leads me to believe you're not using any sort of C XML decoder.
I used the standard library xmlrpclib only.
I'm not saying that XML-RPC is the fastest thing on Earth. I'd be willing to bet it's a lot more interoperable than Gherkin is though:
Agreed. Interoperability was a request in the aforementioned RFE, though it was not an explicit goal of mine. I needed a very fast serialization routine, which could safely unserialize messages from untrusted sources, for sending big chunks of data over TCP. I also needed it to be suitable for use in real-time multiplayer games (my part time hobby). XMLRPC doesn't suit this application. When I control the server, and the client applications, I shouldn't have to use XML. Thanks for the feedback. Simon.