[ratelimits] RRL vs other approaches

[Vernon Schryver]

> > The additional processing you are mentioning is significantly different to 
> > other's findings. I suspect something else changed as well.
> > 
> > Can you rebuild with the RLL patch and see how much your CPU does go up? If
> > it is 2x you can always revert

Is this discussion about the BIND9 RRL patch, the NSD RRL code, some
other RRL code, or something else entirely?
I can only talk about the BIND9 RRL patch.  With no configured limits
(i.e. default), its CPU cost is this test in bin/named/query.c:

	if (client->view->rrl != NULL &&

There are other tests before diving into rate limiting.  I wrote that
test first to minimize the costs of RRL in installations where it is
turned off.

The client and client->view pointers should be in a CPU cache because
of references shortly before.  The client->view->rrl pointer to the
block of RRL parameters might or might not cached depending on the
lengths of cache lines and so forth.  Even if that test suffers cache
misses, so much else that happens before and after that test that I
would doubt any measurements claiming to detect it.

Therefore, you could lose no detectable qps performance by installing
the RRL patch and not turning it on with a response-policy{} statement.
If a performance change is detected, then something unrelated to the
RRL patch is at fault, such as different ./configure parameters, changes
to numbers threads, different libraries (e.g. libc), changes in zones
or even strange things different locations on disk hurting page faulting.

Thus, it would be easy and safe to install the RLL patch and measure
the cost of RRL with varying response-limit{} statements.  That's also
a good way to avoid the effects of unrelated changes.

With configured limits, the worst case is never hitting a limit and
so paying the costs of counting and not saving by not sending
responses.  In that case and with per-query logging enabled so that
every request gets a "consider limiting" log message, I would expect
an easily detectable cost.  However, even in that case a 'much higher
"cost" (2-3x)' is implausible, because of the other per-query messages
at that log level.


Vernon Schryver    vjs at rhyolite.com