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