[Dnsmasq-discuss] How small is a 'small network'?

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It's more complex than number of sockets available to a process. The
number of clients is not limited by the number of sockets. Talking to
clients, one (or a few) sockets handles many clients. Talking
upstream, you need to create a new socket for each query to randomise
the source port, but the code handles that fine: if too many sockets
are in use, it starts to re-use them. The randomness of the source
port falls a bit, but it still keeps working.

The latest release of dnsmasq uses poll() instead of select()
specifically so that it works, and works efficiently, in situations
where the per-process socket limit has been increased above 1024.

The limits with many clients are more on the DHCP side, see my reply
to OP.

Cheers,

Simon.


On 17/11/15 01:00, Jonathan S. Fisher wrote:
> DnsMasq authors, please explain this better than I can... but
> here's my understanding: The limit on number of clients on your
> network will be bounded by DnsMasq's concurrency rate, not
> necessarily the sheer number of clients. DnsMasq is single threaded
> and uses a simple select() fd_set loop ( 
> http://daniel.haxx.se/docs/poll-vs-select.html) which means it
> takes a bunch of file sockets in (I assume each UDP request is a
> socket) then it processes them all and returns control to the OS.
> 1024 seems to be the limit on linux, so I imagine once you approach
> that many concurrent requests I imagine packets will simply be
> dropped since it's UDP.
> 
> With a network of 400 average business users, we see spikes to 200+
> UDP pps, steady state is around 70-80 pps.
> 
> On Mon, Nov 16, 2015 at 4:05 PM, Norman Gray
> <norman at astro.gla.ac.uk> wrote:
> 
>> 
>> Greetings.
>> 
>> The dnsmasq documentation stresses that it's a good solution for
>> 'small networks', but how small is small?  The overview seems to
>> give as examples home networks, or mentions dnsmasq running in a
>> router (implicitly a SOHO router).
>> 
>> I have what I'd call a medium-sized network of machines to look
>> after, which -- depending on how I/we organise the network --
>> could represent between 500 and 1000 machines.  I'd like to
>> provide DHCP and caching DNS to a good fraction of them, and
>> provide authoritative (intranet) records for perhaps half.
>> Dnsmasq looks like it would be very convenient to use for that,
>> but would those numbers tax dnsmasq unduly?
>> 
>> I would guess that DNS and DHCP wouldn't necessarily imply a huge
>> load on a machine, but I'd guess also that the load would scale
>> roughly with the square of the number of machines being served
>> (or perhaps linearly both with the number of machines being
>> served and with the number of authoritative local records).
>> 
>> The machines are heterogenous in use, as opposed to being a
>> compute farm, or something else which would suggest that cache
>> hits would be unusually common.
>> 
>> The manpage mentions that 'Dnsmasq is capable of handling DNS and
>> DHCP for at least a thousand clients.'  That's about the number
>> of clients I'm thinking of, so that's good, but is there a 'with
>> ease' elided there, or a 'without overwhelming pain'?  Would I,
>> in short, be storing up trouble for myself?
>> 
>> I couldn't find discussion of this in a quick search of the list
>> archives, but I wasn't really sure what best to search for.
>> 
>> Thanks for any advice.
>> 
>> Best wishes,
>> 
>> Norman
>> 
>> 
>> -- Norman Gray  :  https://nxg.me.uk SUPA School of Physics and
>> Astronomy, University of Glasgow, UK
>> 
>> _______________________________________________ Dnsmasq-discuss
>> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>> 
> 
> 
> 
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJWS2kNAAoJEBXN2mrhkTWioSQP/2EB0itG2HEmXZbqgaNo11Ft
hW5LsqyfN45nHpdGy6ejlOGK8d802Bay2Almu1L9LeBzMpo0g2SxpRVApTtLoVMs
iIVpV9nRFSpT3YTVfrRjk7FcLRlegcfG8p3DO3pP6b9Uf5AaxnyWK1n79geg19qR
ATcxvMgz7pHYpfAe7TDtuaNzrzNkpVJEFHBXoASvxkrFTjCXECQt33SfAwuc5ONw
64BZRTkhyMVKxx6hD73lWpfJ7UhQWcmTGnQ+wwg7489DvDrXCWN4oEBzKFWT816I
YFIhAbyU8pybh+azEYuwljb+7ts3+MSH/lToEx9/94WZgOFE4Gw2a0K/O6r+broS
BZwHmYAAasc4sovXLiEUbM8AjI7qP0TsOAj7SIJ2MSEeJXq7TzZqFRQPlGKUnlvH
sPodhBWANOAwoGu5FBBexJZ28sUvCxTNIa5BjpqMrG8xKSWe4jb1QZvSJSniRH5C
JS8VRRS3a/lxv/OlhZorRsOvqKCF3VyChTkcsnFgI8dClQpOnEgS96QA7ZEPJpu5
6b3UiOuc0clpkOJw8eubThKJHPlH/KCZthf2Ab6oadySGM+AKEK3L5D6nEAYqa5l
8wvRw3nz2VAL4LgHbikiY+bNhycHtnbS9l4/6hEFJiKMfaU8eQp6hxHd0ZHEtGfz
O8YZgqCL21RKtDqqA0I8
=eN5r
-----END PGP SIGNATURE-----