[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