[bind10-dev] an interesting take on how to do stats

[Michal 'vorner' Vaner]

Hello

On Fri, Dec 17, 2010 at 08:36:40AM -0800, Jerry Scharf wrote:
> At first glance, this seemed like quite a bit of duplicated processing 
> (packet unmarshalling, context switching, etc.) and would slow things 
> down even more. But on a multicore system, this could run almost 
> completely independent of the BIND 10 server, using it's own memory 
> space and not impacting the query processing "fast path" at all.

There are few problems I'd like to point out:

When the packet is sent, it needs to be copied to the pcap and that itself is
likely to slow the answer more than increasing a counter variable.

You have an assumption that there are spare cores/CPUs. For one, that is not
something we want. We want to be able to use all available computation power
(either trough more auth processes or more threads). So eating a core means
slowing down the processing and your suggestion might or might not lover the
latency slightly (but insignificantly compared to the time packets travel over
network), but it would lover the troughput, which are the numbers we want to
advertise AFAIK (nobody cares if the answer takes 300 or 302 microseconds, but
many will care if we can answer 100kQPS or 200kQPS).

Furthermore, you just can't assume that if CPU is completely idle, then you can
run something on it without slowing anything else. When a second CPU runs, it
makes the memory system busy, slowing other memory requests. Of course, you slow
it much less than sharing a single CPU, but it is not for free.

And, finally, writing that kind of tool looks like a lot of work. I think that
investing that amount of work into optimising the code will bring much bigger
boost.

Have a nice day

-- 
Please enter password:

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101217/c5a5162f/attachment.bin>