BIND 10 #2701: DHCPv6 Performance Testing and Enhancement

[BIND 10 Development]

#2701: DHCPv6 Performance Testing and Enhancement
-------------------------------------+-------------------------------------
            Reporter:  marcin        |                        Owner:
                Type:  task          |  marcin
            Priority:  medium        |                       Status:
           Component:  dhcp6         |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-DHCP-20130328
         Sub-Project:  DHCP          |                   Resolution:
Estimated Difficulty:  0             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by tmark):

 * owner:  tmark => marcin


Comment:

 Removal of the call to validate() from OptionDefiniton::optionFactory()
 looks safe. Good catch.

 One thought, would there be any value in adding a with_validate parameter
 (defaults to false/no) to OptionDefinition::optionFactory() and then
 performing
 the validate only when the flag is true/yes?

 --------------------------------------------------------------------------------

 Question on on the memfile composite indexes - did you do monitor memory
 usage
 as well as CPU usage?  While boost is typically very good about memory
 management
 I am a little curious to know how much impact on memory usage this had,
 and to
 ensure it is leak-free.

 On a more minor level, the KeyFromKey naming could perhaps be clearer.

 You aren't really extracting one key from another key, you are extracting
 a "key"
 from within an object hierarchy.  So perhaps KeyFromNestedObject or even
 just
 KeyFrom might be better.  Rather than pass in KeyExtractor1 and
 KeyExtractor2,
 it might be clearer to name them something like  KeyExtractor and
 ObjectExtractor:

     template<typename KeyExtractor, typename ObjectExtractor>
     class KeyFrom {


 Perhaps a little more clarity on the parameter comments themselves would
 be
 sufficient, for example:

     /// @tparam KeyExtractor1 extractor used to access the object used as
     /// a key from the other object that holds it.

 An alternative  "...used to extract the key value from the object
 containing it"

     /// @tparam KeyExtractor2 extractor used to access data in the object
     /// holding nested object used as a key.

 An alternative "... used to extract the nested object containing the key"


 --------------------------------------------------------------------------------

 On commit e0c71421f186a8cf77f1bf7aba7aff072a9caff7, comment says you added
 a
 const, but diff looks like you removed one.

 --------------------------------------------------------------------------------

 Regarding, the documentation changes and new tests under dhcp-val, only
 one
 comment:

 There is a cfg file for memfile testing but it is not mentioned as a test
 case
 in v6.performance.1.txt nor is there a separate test description for it.

 --------------------------------------------------------------------------------

 The types of mysql server tuning parameters discussed in url,while
 interesting,
 fall into the category of site-specific/dba managed values.  Unless they
 can be
 specified on per session, or per database basis we risk undermining some
 other
 use of mysql on the system.

 The callgraphs show, as has been discussed before, that we may have some
 opportunities in how we handle the IPv6 addresses, given that we spend 5%
 of our
 time converting them "fromBytes".   If we move to binary storage in MySQL
 (binary(16)), then we are likely to save both on the conversion we are
 doing
 as well as better index/search peformance from MySQL.

 Overall, this is a very good start at what is far from a trivial effort.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2701#comment:4>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development