BIND 10 #1481: Optimize size on XFR-out

[BIND 10 Development]

#1481: Optimize size on XFR-out
-------------------------------------+-------------------------------------
            Reporter:  shane         |                        Owner:
                Type:  enhancement   |                       Status:  new
            Priority:  minor         |                    Milestone:  New
           Component:  xfrout        |  Tasks
           Sensitive:  0             |                     Keywords:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 https://lists.isc.org/pipermail/bind10-dev/2011-December/002851.html

 During review of #1389, it was discovered, that xfrout splits the stream
 into
 messages in an suboptimal way. Currently, it keeps a sum of RR sizes and
 if this
 overflows, it renders the message and starts a new one.

 But, the rendering compresses names. This means few more RRs could fit in,
 if we
 are lucky and there are lots of similar names (which there usually are, at
 last
 the names of the RRs, if not inside the real data).

 This is not really a big deal, it doesn't break anything. But it generates
 more
 messages and can increase the size of the whole stream, as we can't
 compress
 names across message boundary. Having less messages mean having less
 boundaries
 and more compression.

 So, I'd like to ask, is it worth fixing? There surely are ways to do it
 completely right and fill the messages up to the edge. One would be like
 this:

 {{{
 message = <empty message>
 * Iterate over the RRs to transfer:
   * new_message = message
   * new_message.add(rr)
   * try to render
   * if it overflows:
     * send out message
     * message = <empty message>
     * message.add(rr)
   * else:
     * message = new_message
 }}}

 That is, of course, slow. However, if we could save the renderer state and
 could
 „continue“ with another rr added to the message, it could be made fast (it
 wouldn't make the counts in the headers right, but otherwise, we add RRs
 to the
 end of message).

 So, do you think, is it worth fixing?

-- 
Ticket URL: <http://bind10.isc.org/ticket/1481>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development