From: Tomek Mrugalski Date: Tue, 21 Aug 2012 16:23:06 +0000 (+0200) Subject: [2040] DHCP Performance Guide was updated. X-Git-Tag: trac2351_base~117^2~3 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=cfcd2c6f824e4e00702b76c04ca9b1957ec608a9;p=thirdparty%2Fkea.git [2040] DHCP Performance Guide was updated. --- diff --git a/tests/tools/dhcp-ubench/dhcp-perf-guide.html b/tests/tools/dhcp-ubench/dhcp-perf-guide.html index 61ef948b69..fd1929e901 100644 --- a/tests/tools/dhcp-ubench/dhcp-perf-guide.html +++ b/tests/tools/dhcp-ubench/dhcp-perf-guide.html @@ -1,11 +1,11 @@ -DHCP Performance Guide

DHCP Performance Guide

Tomasz Mrugalski

This is a companion document for BIND 10 version - 20120405.

Copyright © 2012 Internet Systems Consortium, Inc. ("ISC")

Abstract

BIND 10 is a framework that features Domain Name System +DHCP Performance Guide

DHCP Performance Guide

Tomasz Mrugalski

This is a companion document for BIND 10 version + 20120712.

Copyright © 2012 Internet Systems Consortium, Inc. ("ISC")

Abstract

BIND 10 is a framework that features Domain Name System (DNS) suite and Dynamic Host Configuration Protocol (DHCP) servers with development managed by Internet Systems Consortium (ISC). This document describes various aspects of DHCP performance, measurements and tuning. It covers BIND 10 DHCP (codename Kea), existing ISC DHCP4 software, perfdhcp (a DHCP performance - measurement tool) and other related topics.

Table of Contents

Preface
1. Acknowledgements
1. Introduction
2. ISC DHCP 4.x
3. Kea
3.1. Backend performance evaluation
3.2. MySQL backend
3.2.1. MySQL tweaks
3.3. SQLite-ubench
3.3.1. SQLite tweaks
3.4. memfile-ubench
3.4.1. memfile tweaks
3.5. Performance measurements
3.6. Possible further optimizations
4. perfdhcp

List of Tables

3.1. Synchronous results
3.2. Asynchronous results
3.3. Estimated performance

Preface

Table of Contents

1. Acknowledgements

1. Acknowledgements

ISC would like to acknowledge generous support for + measurement tool) and other related topics.

Table of Contents

Preface
1. Acknowledgements
1. Introduction
2. ISC DHCP 4.x
3. Kea
3.1. Backend performance evaluation
3.2. MySQL backend
3.2.1. MySQL tweaks
3.3. SQLite-ubench
3.3.1. SQLite tweaks
3.4. memfile-ubench
3.4.1. memfile tweaks
3.5. Performance measurements
3.6. Possible further optimizations
4. perfdhcp

List of Tables

3.1. Synchronous results
3.2. Asynchronous results
3.3. Estimated performance

Preface

Table of Contents

1. Acknowledgements

1. Acknowledgements

ISC would like to acknowledge generous support for BIND 10 development of DHCPv4 and DHCPv6 components provided by Comcast.

Chapter 1. Introduction

This document is in its early stages of development. It is @@ -15,9 +15,9 @@ tools.

Chapter 2. ISC DHCP 4.x

TODO: Write something about ISC DHCP4 here. -

Chapter 3. Kea

Table of Contents

3.1. Backend performance evaluation
3.2. MySQL backend
3.2.1. MySQL tweaks
3.3. SQLite-ubench
3.3.1. SQLite tweaks
3.4. memfile-ubench
3.4.1. memfile tweaks
3.5. Performance measurements
3.6. Possible further optimizations

+

Chapter 3. Kea

Table of Contents

3.1. Backend performance evaluation
3.2. MySQL backend
3.2.1. MySQL tweaks
3.3. SQLite-ubench
3.3.1. SQLite tweaks
3.4. memfile-ubench
3.4.1. memfile tweaks
3.5. Performance measurements
3.6. Possible further optimizations

-

3.1. Backend performance evaluation

+

3.1. Backend performance evaluation

Kea will support several different database backends, using both popular databases (like MySQL or SQLite) and custom-developed solutions (like in-memory database). BIND 10 @@ -108,9 +108,10 @@ Possible command-line parameters: -n integer - number of test repetitions (MySQL, SQLite and memfile) -s yes|no - synchronous/asynchronous operation (MySQL, SQLite and memfile) -v yes|no - verbose mode (MySQL, SQLite and memfile) + -c yes|no - should compiled statements be used (MySQL only)

-

3.2.1. MySQL tweaks

One parameter that has huge impact on performance is a a backend engine. +

3.2.1. MySQL tweaks

One parameter that has huge impact on performance is a a backend engine. You can get a list of engines of your MySQL implementation by using 

> show engines;

@@ -135,7 +136,7 @@ Possible command-line parameters: switches can be used. Currently supported parameters are (default values specified in brackets):

  1. -f filename - name of the database file ("sqlite.db")

  2. -n num - number of iterations (100)

  3. -s yes|no - should the operations be performend in synchronous (yes) - or asynchronous (no) manner (yes)

  4. -v yes|no - verbose mode. Should the test print out progress? (yes)

+ or asynchronous (no) manner (yes)

  • -v yes|no - verbose mode. Should the test print out progress? (yes)

  • -c yes|no - compiled statements. Should the SQL statements be precompiled?

    • SQLite can run in asynchronous or synchronous mode. This mode can be controlled by using sync parameter. It is set using (PRAGMA synchronous = ON or OFF).

    Another tweakable feature is journal mode. It can be @@ -156,7 +157,7 @@ Possible command-line parameters:

    memfile can run in asynchronous or synchronous mode. This mode can be controlled by using sync parameter. It uses fflush() and fsync() in synchronous mode to make sure that - data is not buffered and physically stored on disk.

    3.5. Performance measurements

    This section contains sample results for backend performance measurements, + data is not buffered and physically stored on disk.

    3.5. Performance measurements

    This section contains sample results for backend performance measurements, taken using microbenchmarks. Tests were conducted on reasonably powerful machine: 

     CPU: Quad-core Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (8 logical cores)
@@ -169,13 +170,13 @@ SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe7
       asynchronous. As those modes offer radically different
       performances, synchronous mode was conducted for 1000 (one
       thousand) repetitions and asynchronous mode was conducted for
-      100000 (hundred thousand) repetitions.
    Table 3.1. Synchronous results
    BackendOperationsCreateSearchUpdateDeleteAverage
    MySQL100031.603978s 0.116612s27.964191s27.695209s21.844998s
    SQLite100061.421356s 0.033283s59.476638s56.034150s44.241357s
    memfile100041.711886s 0.000724s42.267578s42.169679s31.537467s

    Following parameters were measured for asynchronous mode.
+      100000 (hundred thousand) repetitions.
    Table 3.1. Synchronous results
    BackendOperationsCreateSearchUpdateDeleteAverage
    MySQL100031.603978s 0.116612s27.964191s27.695209s21.844998s
    SQLite100061.421356s 0.033283s59.476638s56.034150s44.241357s
    memfile100041.711886s 0.000724s42.267578s42.169679s31.537467s

    Following parameters were measured for asynchronous mode.
       MySQL and SQLite were run with 100 thousand repetitions. Memfile
-      was run for 1 million repetitions due to much larger performance.
    Table 3.2. Asynchronous results
    BackendOperationsCreate [s]Search [s]Update [s]Delete [s]Average [s]
    MySQL10000010.584842s10.386402s10.062384s 8.890197s 9.980956s
    SQLite100000 3.710356s 3.159129s 2.865354s 2.439406s 3.043561s
    memfile1000000 (sic!) 6.084131s 0.862667s 6.018585s 5.146704s 4.528022s

    Presented performance results can be computed into operations per second metrics.
+      was run for 1 million repetitions due to much larger performance.
    Table 3.2. Asynchronous results
    BackendOperationsCreate [s]Search [s]Update [s]Delete [s]Average [s]
    MySQL10000010.584842s10.386402s10.062384s 8.890197s 9.980956s
    SQLite100000 3.710356s 3.159129s 2.865354s 2.439406s 3.043561s
    memfile1000000 (sic!) 6.084131s 0.862667s 6.018585s 5.146704s 4.528022s

    Presented performance results can be computed into operations per second metrics.
       It should be noted that due to large differences between various operations (sometime
       over 3 orders of magnitude), it is difficult to create a simple, readable chart with
       that data.
    Table 3.3. Estimated performance
    BackendCreate [oper/s]Search [oper/s]Update [oper/s]Delete [oper/s]Average [oper/s]
    MySQL (async)9447.479627.979938.0011248.3410065.45
    SQLite (async)26951.5931654.2934899.7040993.5933624.79
    memfile (async)164362.011159195.84166152.01194299.11421002.24
    MySQL (sync)31.648575.4535.7636.112169.74
    SQLite (sync)16.2820045.3716.8117.857524.08
    memfile (sync)23.971381215.4723.6623.71345321.70

    Performance measurements
    Graphical representation of the performance results
-          presented in table Table 3.3, “Estimated performance”.

    3.6. Possible further optimizations

    + presented in table Table 3.3, “Estimated performance”.

    3.6. Possible further optimizations

    For debugging purposes the code was compiled with -g -O0 flags. While majority of the time was spent in backend functions (that was probably compiled with -O2 flags), the diff --git a/tests/tools/dhcp-ubench/dhcp-perf-guide.xml b/tests/tools/dhcp-ubench/dhcp-perf-guide.xml index 6edc5d9906..16bbd63fa9 100644 --- a/tests/tools/dhcp-ubench/dhcp-perf-guide.xml +++ b/tests/tools/dhcp-ubench/dhcp-perf-guide.xml @@ -277,6 +277,7 @@ Possible command-line parameters: -s yes|no - should the operations be performend in synchronous (yes) or asynchronous (no) manner (yes) -v yes|no - verbose mode. Should the test print out progress? (yes) + -c yes|no - compiled statements. Should the SQL statements be precompiled?