MIME-Version: 1.0
In-Reply-To: <950737212.6896402.1398890287894.JavaMail.zimbra@redhat.com>
References: <RT-Ticket-35857@isc.org> <1289346951.5921534.1398691253982.JavaMail.zimbra@redhat.com> <726965977.5930657.1398692151706.JavaMail.zimbra@redhat.com> <rt-3.8.6-35151-1398692154-510.35857-3-0@isc.org> <20140428165852.GA48050@isc.org> <rt-3.8.6-35159-1398704332-1104.35857-5-0@isc.org> <950737212.6896402.1398890287894.JavaMail.zimbra@redhat.com>
Message-ID: <1789975292.2026918.1399878296124.JavaMail.zimbra@redhat.com>
Content-Type: text/plain; charset=utf-8
Subject: Re: [ISC-Bugs #35857] Hardcoded number of handled clients in LWRESD
Thread-Index: rVmoX6v6rODfAwq55cN6xtYCu1qb7gk3g5nN
Date: Mon, 12 May 2014 03:04:56 -0400 (EDT)
Thread-Topic: Hardcoded number of handled clients in LWRESD
To: bind-suggest@isc.org
Content-Transfer-Encoding: 7bit
From: Tomas Hozza <thozza@redhat.com>
RT-Message-ID: <rt-3.8.6-35138-1399878299-667.35857-0-0@isc.org>
Content-Length: 3352

----- Original Message -----
> Hi Evan.
> 
> Thank you for your reply and advices.
> 
> ----- Original Message -----
> > Hi Tomas,
> > 
> > > Is there any specific reason for this? Would you be OK with having
> > > a configuration option(s) in the 'lwres' statement that would
> > > enable setting the NTASKS/NRECVS to a different value?
> > 
> > No, there's no particular reason for that.  The lightweight resolver
> > never got much widespread adoption, so it's been neglected.  (Nobody
> > uses it -> nobody complains about it -> we don't fix broken things.
> > You know how it goes.)
> > 
> > We've actually considered deprecating it, and may yet do so,
> > but in the meantime I'd be happy to accept your patch.  There's a
> > system test in bin/tests/system/lwresd that might be an appropriate
> > place for any regression tests you wish to add.  Documentation
> > goes in chapter 5 of the ARM: doc/arm/Bv9ARM-book.xml.
> 
> I implemented the new options and added documentation (which may require
> some polishing. However I can not think of any use-case that I can add
> into regression tests for those new options. If you have some idea I
> can add some.
> 
> > > Do you have any specific requirements on how such options should
> > > be named?
> > 
> > I would suggest they include "lwres", to clarify that these options
> > only affect lightweight resolver tasks.  I might use "lwres-tasks"
> > and "lwres-clients", for instance, with "lwres-tasks" defaulting to
> > ns_g_cpus (the number of CPUs, potentially overridden by the '-n'
> > option).  Clients would then be evenly divided amongst the tasks.
> > Up to you, though.
> > 
> > > Should there be any (maximum) limit for the values?
> > 
> > Well, at some point you'd hit system resource limits.  Offhand, I'd
> > suggest putting the maximum at 32768 clients, and default to 1024.
> > Perhaps consider using a lower default when running as named and a
> > higher one when running as lwresd.
> 
> I followed your advices and added appropriate default/maximum values.
> Please see the commit message.
> 
> > The way clients work in lwresd is, unfortunately, broken and stupid.
> > In named, when it's necessary to recurse to answer a client query, the
> > ns_client object that handled the incoming query will replace itself
> > so that if more queries come in while it's recursing, there will be
> > another ns_client object there to handle them.  The lwd_client
> > objects used for the lightweight resolver don't do this.  If you get
> > them all busy doing recursion, all incoming queries are starved.
> > If we don't end up deprecating LWD, then one of these days we really
> > ought to combine its client-management code with ns_client.
> >
> > --
> > Evan Hunt -- each@isc.org
> > Internet Systems Consortium, Inc.
>  
> If you see anything in my patch that could be improved, please let me know.
> 
> Thank you!
> 
> Regards,
> --
> Tomas Hozza
> Software Engineer - EMEA ENG Developer Experience
> 
> PGP: 1D9F3C2D
> Red Hat Inc.                               http://cz.redhat.com

Hello.

I would like to ask you for a feedback for the patch I sent you
last time, so I can proceed with it, or fix found issues.

Thanks!

Regards,

-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com