On 10 Aug 2000 08:10:01 -0500, Jim Fulton wrote:
>Michel Pelletier wrote:
>> Jim Fulton wrote:
>> > Michel Pelletier wrote:
>> > > Also, ZClient
>> > > is much faster i've found, probably due to the marshalling/unmarshalling
>> > > necessary for xml-rpc.
>> > That's interesting......Hm. ZClient has to marshal. I suspect that
>> > xml-rpc wants some sort of optimization.
>> I made a test script to make about 300 xmlrpc calls to various manage_
>> methods. I had to kill it after about a half-hour cuz it was takin so
>This sounds pretty fishy. Are you saying that you made less than
>300 calls in half an hour? This doesn't seem right at all.
I'm probably way off base here, but I use xml-rpc to transfer
records to a Zope-based application from a bunch of Macs attached
to ABI gene sequencers. The data is simple lists of lists and it
*appears* to take about 2-3 seconds for the Macs to xml-encode and
transfer the data as-is, but it takes typically *3 minutes* for
the xmlrpc server to decode and rebuild the table data. This is
for about 6000 records representing about 200k of text data (Sun
Ultra 5 server). However, if I simply build a string representation
of the table data, it takes about 3-4 seconds for the client to
stringify, transfer the string data, and the server to reconstruct
the table. Guess which method I use?
The tests I ran using a SAX-based parser show it might parse and
rebuild the data at least 50x faster than the current Python-only
Now maybe something else is going on wrt manage* methods and xmlrpc,
(I'm using external methods for managing the data transfer and am
not storing the raw data in the Zope database), but my external
methods-based calls rip along at a pretty good clip as long as I
convert the data to a (few) string(s) before sending.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -