[Python-Dev] PEP for RFE 46738 (first draft)

[Simon Wittber]

> 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.