On Thu, 6 Nov 2014 12:01:11 -0500 Tom Cameron <[email protected]> wrote:
> I suppose you could hash on the source address note that we would have to make sure that given keys are always processed together, i.e. if doing this, multiple sources can't send packets with the same key (typically people encode hostname in their statsd keys so this helps) > This is why when you see most examples of using TCP connections in any > language, a thread (or Goroutine) is spun up to handle a TCP client. The > server can service many TCP clients concurrently, and the persistence of > the session with the client lends itself to just having an idle thread > listening for more data. With UDP, you can't do any of this. Well, you > can't practically do any of this. I guess we could mimic this by listening on a whole bunch of different udp ports. not saying we should, though ;) anyway, i just did some crude testing. on an intel xeon E5-2690 @ 2.90GHz heka consumes 70~80% cpu typically, when i send around 75k timers/s and 40k counters/s and once in a while it'll drop some packets from the udp buffer. (like 10k every minute or so) this is with stat accumulator every 60s; enabling dashboard and looking at a realtime graph with 3 series tracked does not seem to impact cpu at all. again, quick and crude test. but it seems pretty good and at least in the same order of what i got with statsdaemon. _______________________________________________ Heka mailing list [email protected] https://mail.mozilla.org/listinfo/heka
