[libvirt] [RFC][scale] new API for querying domains stats

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140703/439da011/attachment-0001.sig>