On 8/17/06, David Hirschfield <[EMAIL PROTECTED]> wrote: > I have an xmlrpc client/server system that works fine, but I want to > improve performance on the client side. > > Right now the system operates like this: > > client makes request from server (by calling server.request() via xml-rpc) > server places "request" on queue and returns a unique ID to the calling > client > client repeatedly asks server if the request with the given ID is > complete via server.isComplete(<id>) > server eventually completes processing request > client eventually gets an affirmative from server.isComplete(<id>) and then > client pulls results from server via server.fetchResults(<id>) > > originally the client only made one request at a time, and each one was > processed and results fetched in order. > > I want to change this so that the client can send multiple requests to > the server and have them processed in the background. > There are a lot of different approaches to that process, and I'd like > advice on the best way to go about it. > > I could simply place the request checking and results fetching into a > thread or thread-pool so that the client can submit requests to some > kind of queue and the thread will handle submitting the requests from > that queue, checking for completion and fetching results. > > Unfortunately, that would mean lots of calls to the server asking if > each of the requests is complete yet (if I submit 100 requests, I'll be > repeatedly making 100 "are you done yet?" calls). I want to avoid that, > so I thought there would be some way to submit the request and then hold > open the connection to the server and wait on the completion, but still > allow the server to do work. > > Any advice on how to avoid polling the server over and over for request > completion, but also allowing the client to submit multiple requests > without waiting for each one to finish before submitting the next?
One obvious improvement over your current scheme would be that instead of polling server for each request submitted, have a unified polling mechanism wherein server returns a list of "ids" of all processed request. But as you too mentioned polling is "often" not the best way, You may try say: 1. Upon submitting a request, client-server agree upon a port on which client will listen for the results. 2. Registering a callback function. (Googling would point to more elaborate discussions on pros and cons ) cheers, amit. ---- Amit Khemka -- onyomo.com Home Page: www.cse.iitd.ernet.in/~csd00377 Endless the world's turn, endless the sun's Spinning, Endless the quest; I turn again, back to my own beginning, And here, find rest. -- http://mail.python.org/mailman/listinfo/python-list
