| Subject: | FW: Statistics channel patch |
| Date: | Wed, 15 Sep 2010 14:36:02 -0400 |
| To: | <bind-suggest@isc.org> |
| From: | "Timothe Litt" <litt@acm.org> |
I was advised that you want suggestions at this address - sorry for any
duplication.
Timothe Litt
ACM Distinguished Engineer
---------------------------------------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-----Original Message-----
From: Timothe Litt [mailto:litt@acm.org]
Sent: Monday, September 13, 2010 15:46
To: 'bind-users@lists.isc.org'
Subject: Statistics channel patch
I have found the statistics channel useful for getting the active zone
configuration - this lets my management GUI autoconfigure validity checks
and pull-down menus for zones. This will be especially helpful when the
dynamic add/delete zone situation is sorted out. But it's useful now
because it avoids having the GUI follow all the nested includes of named's
config files -- or, as that's so ugly, the separate configuration that I had
before.
However, I ran into a few issues with this approach:
o There is no way to distinguish a built-in zone from a user zone. I
currently use serial == 0, but that's not guaranteed. Of course, _bind is
in the CH domain, but that still leaves the built-in private address zones
(like 8.B.D.0.1.0.0.2.IP6.ARPA/IN/internal).
o The vast quantity of statistics are quite a lot for a perl XML parser to
handle - especially on older machines. (XML::Simple using XML::Parser on a
400MHz machine takes 20 seconds because the structure of the XML generates
zillions of deeply nested anonymous hashes!)
o I build quite a few data structures, and want to cache them. But it's
really hard (computes and lines of code) to separate out the dynamic data
(statistics) from the fairly static (configured zones). In fact, the zone
serial number, which is not relevant for configuration, is in that section.
So it would require field by field decisions, and on-going maintenance.
This resulted in the attached patch, which others may find useful (and I'd
be really happy if it made it into the next release in some form).
It implements the /config URL on the statistics channel. /config returns
everything that's "fairly static". (e.g. If it weren't for dynamic zone
addition/deletion, you'd find it in a config file - not a zone file or
memory.)
It uses exactly the same XML structure as the current / URL and in fact uses
the same code.
It also adds a <type> tag, with the values "builtin" or "user". (This is
still based on serial == 0, but perhaps someone can find a better way to
make the determination.) Except for this addition, the / URL's output is
unchanged.
With this, it's possible to do a simple hash of the returned data and
invalidate the cache when it differs from the stored hash of the cached
copy. This gets the whole thing down to ~1sec even on my slow machine,
which is quite tolerable.
It should be easy to add any other useful data, as long as the rule that
/config must not have rapidly changing data is obeyed.
I did not update the XSL to understand that the dynamic stuff is now
optional. It just shows up as blank if you use a web browser.
A side note - I was surprised that the <view><zones><zone><name> is of the
form "name/class/view", since class and view names are available as separate
tags. Easy enough to deal with, but it might be worth considering removing
the redundant /class/view from the name at some point. I didn't because I
wanted to stay compatible with the mainline.
The patch only looks large - as kdiff3 would show, it's mostly indentation
where I skip over the unwanted statistics when responding to the new URL.
About 16 non-whitespace changes, mostly 1 line.
Enjoy.
---------------------------------------------------------
This communication may not represent the ACM or my employer's views, if any,
on the matters discussed.
Message body not shown because it is not plain text.