Henrique Dante de Almeida schrieb:
On May 16, 9:26 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
Did you consider gzipping your XML (or YAML) packets ? Would the
transfer time be acceptable in this case ?
That would add even more to the overhead of transcoding the
transportlayer. Switching from XMLRPC to a json-based protocol reduced
Yes, that's why I suggested YAML.
in a project of mine reduced the overhead 10-20fold - mainly because of
reduced size and parsing efforts.
I don't think so. It probably just the reduced size (check if the
json file is around 10 times smaller).
I believe the server will be mostly I/O-bound, ie, most overhead will
be in the data link/physical layers. The compression/parsing time (a
few microseconds) should be a small fraction of the total transfer
time (a few milliseconds). Even if the service is not I/O bound,
(considering the Youtube example) if there's significant traffic in
the server, the database access time should be the most significant.
I have used compression for SOAP messages in a GPRS (~20kbps) link
and got similar performance improvements (the web server was set to
automatically compress the data).
I'm sorry, yes - I forgot that the main problem was the pure message
size due to some quadratic behaviour, which made things CPU-bound.
Still, XML-parsing is much more expensive, and packing/unpacking will of
course add to that.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
