On 07/01/2014 03:33 AM, Daniel P. Berrange wrote:
1. Time to write() the RPC call to the socket
2. Time for libvirtd to process the RPC call
3. Time to recv() the RPC reply from the socket
...and so on..
If the time for item 2 dominates over the time for items 1 & 2 (which
it should really) then the client thread is going to be sleeping in a
poll() for the bulk of the duration of the libvirt API call. If we had
an async API mechanism, then the VDSM time would essentially be consumed
with
1. Time to write() the RPC call to the socket
2. Time to write() the RPC call to the socket
3. Time to write() the RPC call to the socket
4. Time to write() the RPC call to the socket
5. Time to write() the RPC call to the socket
6. Time to write() the RPC call to the socket
7. wait for replies to start arriving
8. Time to recv() the RPC reply from the socket
9. Time to recv() the RPC reply from the socket
10. Time to recv() the RPC reply from the socket
11. Time to recv() the RPC reply from the socket
12. Time to recv() the RPC reply from the socket
13. Time to recv() the RPC reply from the socket
14. Time to recv() the RPC reply from the socket
This assumes you are still calling one async call per domain query.
With regards to a bulk API, are you thinking synchronous?
1. Time to write() the RPC call - one bulk request
2. wait for reply - oh, and we'd better increase our on-wire size limits
3. Time to recv() the RPC reply - one bulk response
or asynchronous?
1. Time to write() the RPC call - one bulk request
2. wait for replies to start arriving
3. Time to recv() an RPC async reply - first domain
4. Time to recv() an RPC async reply - second domain
...
n. Time to recv() final RPC async reply
The asynchronous works nicely in that we don't have to size up our max
RPC on-wire limits, but implies that you still need a callback invoked
once per reply received, instead of getting all data back in one giant
memory blob.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org