Hello. On Mon, 2005-05-09 at 10:53 -0700, Federico D. Sacerdoti wrote: > Andrew, > I pretty much agree with you on all these points. More specific answers > below. Thanks.
> > > > You are right. We should think about moving the DTD retrieval to > another URL rather than tacking it on to each response. > > # nc localhost 8652 > /?filter=DTD > > or similar. That'd be good. On Sun, 2005-02-20 at 07:54 -0800, Federico Sacerdoti wrote: > > And what about the compression of this data? > > For a lot of nodes the compression can reduce the amount of the data > > essentially. > > There is always a tradeoff between compute and network resources with > compression. If you have fast networks and highly stressed nodes, > compression is bad. It also hurts response time for the web frontend. > If you have thin networks and lots of free cycles (PlanetLab for > example) then compression is good. Matt had some code to give you a > choice, not sure on its status. > > I can't find any code (3.0.0) or configuration parameters but just some remarks in ChangeLog. As far as I see in ChangeLog the compression can be applied to gmetad<- >gmetad and gmetad<->gmond connection. But I meant the gmetad<->client channel compression e.g.: /?filter=zsummary returns compressed stream for a /?filter=summary. What about it? Is it possible? My friend has started a work on monitoring client: http://sourceforge.net/projects/grate/ and I try to help him in gmetad<->client communication. I want to participate in gmetad development: extended filters, compression, encryption (SSL) are the things the most interesting for me. I also can translate the available documentation or something else (web- page, web front-end) into Russian. Is the translation should be send in the form of patch. Andrew Sapronov
signature.asc
Description: This is a digitally signed message part
