[bind10-dev] optimization: use some additional polling in SyncUDPServer
Shane Kerr
shane at isc.org
Wed Jul 4 18:25:53 UTC 2012
JINMEI,
On Monday, 2012-07-02 11:34:32 -0700,
JINMEI Tatuya / 神明達哉 <jinmei at isc.org> wrote:
>
> 1recv/ev is equivalent to what we currently do.
> Nrecv/ev (N>0) are the optimized versions, varying the number of max
> queries that can be handled at once.
<snip/>
> 10% is not very big, but the required change should be pretty small
> (it will be about 50-line additional code, completely local to the
> SyncUDPServer class), so I think it's worth doing.
I agree.
> The major drawback of this optimization is that if the server has
> multiple interfaces (today many servers have at least two: one for
> IPv6 and the other for IPv4), this optimization could worsen the
> worst case latency (the next query in the other IF needs to wait
> until all N-queries in the first IF are handled). But, I guess with
> a reasonably chosen limit it's acceptable - if the server can handle
> 20K queries/s in average, the delay for handling 10 queries is about
> 0.5ms. Also, if the server runs multiple instance of b10-auth, it's
> more likely that queries from different IFs are handled in different
> instances with higher concurrency.
This is exactly the kind of trade-off that Joao means when he talks
about trading latency for throughput then.
A related risk is overflowing kernel UDP buffers because of this
delay; for example if we are getting IPv4 queries at a rate 10x that of
IPv6, then there might be enough IPv6 queries to keep us iterating for
4 or 5 queries when 40 or 50 pile up on the IPv4 side.
Still, overall I think this is clearly a "win".
> So I suggest we include this optimization some time with the current
> (coming) scalability work.
I've made a ticket for this:
http://bind10.isc.org/ticket/2118
> Two additional notes:
> - The amount of improvement (10%) matches my memory about the overhead
> of ASIO abstraction I mentioned in the last f2f meeting.
> - The same optimization will work well for the resolver.
Is this something that makes sense for BIND 9 too do you think? They
don't use ASIO but presumably the select/poll mechanism could be
short-circuited in a similar way for an easy win?
Cheers,
--
Shane
More information about the bind10-dev
mailing list