On 02/06/14 18:23, John Else wrote: > >> - Have you considered using vchan to let other tools capture the rrd stream >> more easily? > I hadn't, but I think that could be made to work. At the moment the protocols > expect the shared-memory resource to be represented as a cstruct so it would > need a bit of tweaking to work with a socket-style interface instead. > > I also wanted to keep the library free of dependencies to any particular > handshake mechanism (e.g. xenstore), so I think the right interface would be > to start with a ready-initialised vchan server and turn that into a reader > (or conversely turn a vchan client into a writer). A nice aspect of the current simple shared-memory design is that it desynchronises reader and writer, so the writer can simply update its page without worrying that the reader has died and isn't going to drain the queue. It also means that the reader degrades nicely as the number of data sources increases - it can simply sample less frequently. This works best for DERIVE type data sources where the writer maintains a monotonically increasing count of which the interesting thing is the derivative (e.g. CPU time, or VIF bytes transmitted).
I think we should strive for the principle that observing the stats should have as little impact as possible on the thing being observed, so removing synchronisation points seems like a good idea. We clearly want to avoid the Consciousness Causes Collapse problem :-) Jon _______________________________________________ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
