Re: [RFC][scale] new API for querying domains stats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]