BIND 10 #2606: DHCP Performance Testing and Enhancement

[BIND 10 Development]

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

 * owner:  marcin => tmark


Comment:

 Replying to [comment:5 tmark]:
 > Overall, very well done given the rather informal requirements.

 Thanks!

 >
 > A few questions:
 >
 > 1. Should there by any prerequisite statements to determine what if any
 other load
 > exists on either machine and/or network?  Would it be helpful to have
 gathered some
 > basic network metrics, ping time etc?
 >
 > 2. Should Test Procedure include statements indicating a required level
 of isolation
 > or to ensure that there is no other traffic against the bind10 or its
 components.
 > For example, on the DHCP test lab,  the windows boxes apparently are
 always trolling
 > DHCP4 through out the lab. This introduces spurious traffic.
 >
 I updated the test procedure to reflect that the influence of other
 processes running on the test systems or existing network traffic should
 be eliminated. On the other hand I didn't want to give specific step-by-
 step instructions how to eliminate the influence of the world on the test
 because the setup may vary (use cross-connect, VLAN etc) and different
 conditions should be taken into account. In my opinion, it is often better
 to leave it up to the test executor to make sure that the machines and
 network setup is appropriate, otherwise he or she just blindly follows the
 step-by-step instructions.

 > Pertaining to the output collected.  It would be perhaps, helpful to
 have the
 > charts together on a single sheet, maybe stacked vertically. Also the
 legend does
 > not specify units of measure for time.

 Perhaps the data formatting could be better. Note however that the test
 procedure does not mandate any specific format to present the data. In my
 opinion the data tables are still readable and the appropriate conclusions
 can be drawn out of it. The results presented in the spreadsheet may be
 used in the future to create the Performance Guide document. In such case
 the presentation will be of a great importance because customers will be
 reading it. For now, I suggest we leave it as is because we use it for
 internal purposes only.

 I have uploaded the new version of the spreadsheet with units of measure
 added to the tables.

 >
 > Minor comment on dhcp-val/doc/performance-test-setup.txt:
 >
 >     In the paragraph, near the end of document:
 >
 >     " The server system should already have all prerequsities needed to
 build BIND10 installed.
 >     In case any of them is missing for any reason, please refer to
 BIND10 System Specific Notes
 >     for the BIND10 setup on the FreeBSD:
 http://bind10.isc.org/wiki/SystemNotesFreeBSD"
 >
 >     I believe you should replace "server" with "client" or
 "perf-s1.lab".

 Good catch. I fixed that.

 >
 > An observation:
 >
 > It is interesting that regardless of the backend employed and the ex
 rate, the average delay
 > time is essentially the same until you hit a level that overwhelms the
 system and the drop rate
 > gets large.  In other words, the minimum response time doesn't really
 change until you break the
 > system.

 In fact, the minimum response time does not change even if the system is
 overwhelmed. What does change is the maximum response time and thus
 average response time. I am not surprised with it. The shortest response
 time most likely occurs on the beginning of the test when the lease table
 is empty and the overhead related to searching for existing leases is
 minimal.
 The maximal response time occurs when the server spends more time
 processing new leases in MySQL than handling communication with the client
 so many of the incoming or outgoing packets are stuck in the server doing
 some other job.

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