In message <20000708180256W.he@runit.sintef.no>,
Havard.Eidnes@runit.sintef.no writes:
>
>Are you saying that all your requestors each use their own
>permanent TCP socket towards the name server providing recursive
>lookup service?  Is there a particular reason that the resolver
>clients can't use UDP instead?  If you did, I would think that the
>FD_SETSIZE issue on the default named goes away.

No, the requestors are using UDP and the standard netbsd resolver
(which means one process per requestor).

As to why increasing FD_SETSIZE (and doing "limit 1024" or "limit
2048" or whatever i have today) increases thourghput: i have no idea.

>This of course won't solve all the other more generic problems in
>bind8 e.g. related to handling many outstanding queries, but that's
>a different kettle of fish.

Well, it *seems* to increase the number of outstanding queries I can
handle by a small factor (say, about 3x). Again, i have no idea (yet)
why that is.


Upping named's FD_SETSIZE is (of course) a different issue from
whether FD_SETSIZE == 256 is a good or adequate default limit for
precompiled binaries (apps and libraries) on all the machines we support.