Hi,
with https://github.com/vimeo/statsdaemon, our statsd replacement in go (1.3)
we are processing between 40~70k messages a second (10k timers/s, 500 gauges/s
and the rest is counters), and:
* cpu (Xeon E5-2697 v2 @ 2.70GHz) is typically 70~90% used with the occasional
100% (increasing GOMAXPR
Getting caught up on backlog sorry for the delay.
On 10/18/2014 01:06 PM, Dieter Plaetinck wrote:
So I plan to do some experimenting with heka, but meanwhile I'ld like to hear
from you.
1) does anyone have some empirical numbers on heka-as-statsd performance? in
particular, when does it
On Tue, 04 Nov 2014 11:22:00 -0800
Rob Miller wrote:
> Getting caught up on backlog sorry for the delay.
>
> On 10/18/2014 01:06 PM, Dieter Plaetinck wrote:
> >
> > So I plan to do some experimenting with heka, but meanwhile I'ld like to
> > hear from you.
> >
> > 1) does anyone have some e
On 4 November 2014 19:22, Rob Miller wrote:
> On 10/18/2014 01:06 PM, Dieter Plaetinck wrote:
>>
>> 3) does heka leverage multi-core properly for the statsd workload
>> (receiving the packets, and doing the aggregations)?
>>
> Not sure what you mean by "properly", but it is true that the StatsdIn
> i was thinking along the lines of spreading the workload of reading
packets and/or computing the aggregate stats (timer,counter, ..) for all
metric keys (stataccum) across different cores, because in my experience
those parts are most cpu intense and could (in theory) be fairly easily
parallelize
On Thu, 6 Nov 2014 09:30:48 -0500
Tom Cameron wrote:
> But, I suspect the
> cost of disassembling packets is higher than the math you're going to do.
> This is made more true by the fact that you need shared (locked) structures
> for your counts.
i was thinking of having N workers, where every w
>
> i was thinking of having N workers, where every worker is responsible for
> a certain subset of the key space.
> e.g. using consistent hashing, the processing for all metric lines
> relating to an individual key requires no outside data.
> But at the same time, I think you're right that reading
On Thu, 6 Nov 2014 12:01:11 -0500
Tom Cameron 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
On 11/07/2014 09:51 AM, Dieter Plaetinck wrote:
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 minut
On Fri, 07 Nov 2014 09:56:47 -0800
Rob Miller wrote:
> On 11/07/2014 09:51 AM, Dieter Plaetinck wrote:
> > 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
On 11/07/2014 12:38 PM, Dieter Plaetinck wrote:
On Fri, 07 Nov 2014 09:56:47 -0800
Rob Miller wrote:
> On 11/07/2014 09:51 AM, Dieter Plaetinck wrote:
>> 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 time
11 matches
Mail list logo
