On Fri, Oct 16, 2009 at 01:36:52PM -0700, Hank A. Paulson wrote: > For the code you are developing, if you make the interface general enough > so that parameters can be added or removed that would be good. > Telnet/text/memcached style protocols seem popular to allow easy > debugging/monitoring. > So if your protocol says a machine has to send a load info bundle like: > SS:8cbed340118ddf87e2d8ca4352006572 > SYSID: blah1 > SAMPLETIME: 2009-10-14-22-00-03 > CPU: 83.23343455 > NETI: 134238.0232 > NETO: 492283.6549 > DISK: 433.232 > ES:8cbed340118ddf87e2d8ca4352006572
It's a lot better to return these information in HTTP headers, because that can be added on top of any other resource that haproxy would check. (...) > It is probably possible to just modify feedbackd to emit haproxy "set > weight" commands. Don't do that ! The "set weight" is for the human, not for an automaton. The most interesting usage is "set weight xx/xx 0" to disable a server before operating on it, or "set weight xx/xx 50%" to off-load it a bit if you see it start swapping. If you send an automated tool on it, it will constantly change your manually assigned values. > More interesting, I think would be to combine a multiple load parameter > (active connections, CPU, net in/out bytes, net in/out packets, disk io, > etc) feedback system with the ideas from the NetBSD neural network > scheduler, creating an ai based dynamic load balancing system. > http://softlayer.dl.sourceforge.net/project/nnsched/docs/thesis/nnsched.pdf > This is more possible now that we have multi core systems that would have > some idle CPU resources available for the ai compute load. if doing some computations on that few parameters consumes even a measurable amount of CPU, then they are clearly wrong. We're not doing fractals here. Combining 3-4 parameters should not results on billions of operations. Willy
