%version; ]> Various aspects of DHCP Performance in BIND 10 2012Internet Systems Consortium, Inc. Tomasz Mrugalski 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. This is a companion document for BIND 10 version &__VERSION__;.

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

This document is in its early stages of development. It is expected to grow significantly in a near future. It will cover topics like database backend perfomance measurements, pros an cons of various optimization techniques and tools. TODO: Write something about ISC DHCP4 here.

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 source code features set of performance microbenchmarks. These are small tools written in C/C++ that simulate expected DHCP server behaviour and evaluate the performance of considered databases. Those benchmarks are stored in tests/tools/dhcp-ubench directory. This directory contains simplified prototypes for various DB back-ends that are planned or considered as a backend engine for BIND10 DHCP. Athough trivial now, they are expected to evolve into useful tools that will allow users to measure performance in their specific environment. Currently the following benchmarks are implemented: in memory+flat file SQLite MySQL As they require additional (sometimes heavy) dependencies, they are not built by default. Actually, their build system is completely separated. It will be eventually merged with the main BIND10 makefile system, but that is a low priority for now. All benchmarks will follow the same pattern: prepare operation (connect to a database, create a file etc.) Measure timestamp 0 Commit new lease4 (repeated X times) Measure timestamp 1 Search for random lease4 (repeated X times) Measure timestamp 2 Update existing lease4 (repeated X times) Measure timestamp 3 Delete existing lease4 (repeated X times) Measure timestamp 4 Print out statistics, based on X and measured timestamps. Although this approach does not attempt to simulate actual DHCP server operation that has mix of all steps intervening, it answers the questions about basic database strenghts and weak points. In particular it can show what is the impact of specific DB optimizations, like changing engine, optimizing for writes/reads etc. The framework attempts to do the same amount of operations for every backend thus allowing fair complarison between them.

MySQL backend requires MySQL client development libraries. It uses mysql_config tool (that works similar to pkg-config) to discover required compilation and linking options. To install required packages on Ubuntu, use the following command: $ sudo apt-get install mysql-client mysql-server libmysqlclient-dev Make sure that MySQL server is running. Make sure that you have your setup configured so there is a user that is able to modify used database. Before running tests, you need to initialize your database. You can use mysql.schema script for that purpose. WARNING: It will drop existing Kea database. Do not run this on your production server. Assuming your MySQL user is kea, you can initialize your test database by: $ mysql -u kea -p < mysql.schema After database is initialized, you are ready to run the test: $ ./mysql_ubench or $ ./mysql_ubench > results->mysql.txt Redirecting output to a file is important, because for each operation there is a single character printed to show progress. If you have a slow terminal, this may considerably affect test perfromance. On the other hand, printing something after each operation is required, as poor DB setting may slow down operations to around 20 per second. Observant user is expected to note that initial dots are printed too slowly and abort the test. Currently all parameters are hardcoded. To modify them, one needs to modify source code and recompile. Fortunately, that is quite easy. To modify MySQL parameters, see main() method at the end of mysql_ubench.c file. That is the plase where one can modify MySQL connection parameters (MySQL server hostname, user and password and database name).

To reconfigure mysql_ubench parameters, a modification to the source code and recompilation is required. All parameters are listed in main() function in mysql_ubench.cc file, near the end of the file. Currently supported parameter are (default values specified in brackets): hostname - name of the host to connect to ("localhost") user - MySQL username ("root") passwd - MySQL password ("secret") dbname - MySQL database name ("kea") num - number of iterations (100) sync - should the operations be performend in synchronous (true) or asynchronous (false) manner (true) verbose - should the test print out progress? (true) 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; in your mysql client. Two notable engines are MyISAM and InnoDB. mysql_ubench will use MyISAM for synchronous mode and InnoDB for asynchronous.

SQLite backend requires both sqlite3 development and run-time package. Their names may vary from system to system, but on Ubuntu 12.04 they are called sqlite3 libsqlite3-dev. To install them, use the following command: > sudo apt-get install sqlite3 libsqlite3-dev Before running the test the database has to be created. Use the following command for that: > cat sqlite.schema | sqlite3 sqlite.db A new database called sqlite.db will be created. That is the default name used by sqlite_ubench test. If you prefer other name, make sure you update sqlite_ubench.cc accordingly. Once the database is created, you can run tests: > ./sqlite_ubench or > ./sqlite_ubench > results-sqlite.txt

To reconfigure sqlite_ubench parameters, a modification to the source code and recompilation is required. All parameters are listed in main() function in sqlite_ubench.cc file, near the end of the file. Currently supported parameter are (default values specified in brackets): filename - name of the database file ("sqlite.db") num - number of iterations (100) sync - should the operations be performend in synchronous (true) or asynchronous (false) manner (true) verbose - should the test print out progress? (true) 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 turned to several modes of operation. Its value can be modified in SQLite_uBenchmark::connect(). See http://www.sqlite.org/pragma.html#pragma_journal_mode for detailed explanantion.

TODO

...

TODO: Write something about perfdhcp here.