Accueil Explorer Aide
Connexion
zorun
/
kea
1
0
Fork 0
Fichiers Tickets 0 Pull Requests 0 Wiki
Aborescence: 7ece465eff
Branches Tags
kea
/
tests
/
tools
/
dhcp-ubench
/
dhcp-perf-guide.html

dhcp-perf-guide.html 39 KB
Historique Raw

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289 
  1. <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>DHCP Performance Guide</title><link rel="stylesheet" type="text/css" href="bind10-guide.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"><meta name="description" content="BIND 10 is a framework that features Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP) software 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."></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" title="DHCP Performance Guide"><div class="titlepage"><div><div><h1 class="title"><a name="idm25635296"></a>DHCP Performance Guide</h1></div><div><div class="author"><h3 class="author"><span class="firstname">Tomasz</span> <span class="surname">Mrugalski</span></h3></div></div><div><p class="releaseinfo">This is a companion document for BIND 10 version
    2. 

  2.     20120712.</p></div><div><p class="copyright">Copyright © 2012 Internet Systems Consortium, Inc. ("ISC")</p></div><div><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>BIND 10 is a framework that features Domain Name System
    3. 

  3.       (DNS) and Dynamic Host Configuration Protocol (DHCP)
    4. 

  4.       software with development managed by Internet Systems Consortium (ISC).
    5. 

  5.       This document describes various aspects of DHCP performance,
    6. 

  6.       measurements and tuning. It covers BIND 10 DHCP (codename Kea),
    7. 

  7.       existing ISC DHCP4 software, perfdhcp (a DHCP performance
    8. 

  8.       measurement tool) and other related topics.</p></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#idp31744">Preface</a></span></dt><dd><dl><dt><span class="section"><a href="#acknowledgements">1. Acknowledgements</a></span></dt></dl></dd><dt><span class="chapter"><a href="#intro">1. Introduction</a></span></dt><dt><span class="chapter"><a href="#dhcp4">2. ISC DHCP 4.x</a></span></dt><dt><span class="chapter"><a href="#kea">3. Kea</a></span></dt><dd><dl><dt><span class="section"><a href="#idp40176">3.1. Backend performance evaluation</a></span></dt><dt><span class="section"><a href="#mysql-backend">3.2. MySQL backend</a></span></dt><dd><dl><dt><span class="section"><a href="#idp64224">3.2.1. MySQL tweaks</a></span></dt></dl></dd><dt><span class="section"><a href="#sqlite-ubench">3.3. SQLite-ubench</a></span></dt><dd><dl><dt><span class="section"><a href="#sqlite-tweaks">3.3.1. SQLite tweaks</a></span></dt></dl></dd><dt><span class="section"><a href="#memfile-ubench">3.4. memfile-ubench</a></span></dt><dd><dl><dt><span class="section"><a href="#memfile-tweaks">3.4.1. memfile tweaks</a></span></dt></dl></dd><dt><span class="section"><a href="#idp104752">3.5. Basic performance measurements</a></span></dt><dt><span class="section"><a href="#idm38464">3.6. Optimized performance measurements</a></span></dt><dt><span class="section"><a href="#idp275344">3.7. Conclusions</a></span></dt><dt><span class="section"><a href="#idp281328">3.8. Possible further optimizations</a></span></dt></dl></dd><dt><span class="chapter"><a href="#perfdhcp">4. perfdhcp</a></span></dt></dl></div><div class="list-of-tables"><p><b>List of Tables</b></p><dl><dt>3.1. <a href="#idp108384">Synchronous results (basic)</a></dt><dt>3.2. <a href="#idp129440">Asynchronous results (basic)</a></dt><dt>3.3. <a href="#tbl-basic-perf-results">Estimated basic performance</a></dt><dt>3.4. <a href="#idp204944">Synchronous results (optimized)</a></dt><dt>3.5. <a href="#idp225424">Asynchronous results (optimized)</a></dt><dt>3.6. <a href="#tbl-optim-perf-results">Estimated optimized performance</a></dt></dl></div><div class="preface" title="Preface"><div class="titlepage"><div><div><h2 class="title"><a name="idp31744"></a>Preface</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#acknowledgements">1. Acknowledgements</a></span></dt></dl></div><div class="section" title="1. Acknowledgements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="acknowledgements"></a>1. Acknowledgements</h2></div></div></div><p>ISC would like to acknowledge generous support for
    9. 

  9.       BIND 10 development of DHCPv4 and DHCPv6 components provided
    10. 

  10.       by <a class="ulink" href="http://www.comcast.com/" target="_top">Comcast</a>.</p></div></div><div class="chapter" title="Chapter 1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a name="intro"></a>Chapter 1. Introduction</h2></div></div></div><p>
    11. 

  11.       This document is in the early stages of development. It is
    12. 

  12.       expected to grow significantly in the near future. It will
    13. 

  13.       cover topics like database backend perfomance measurements,
    14. 

  14.       tools, and the pros an cons of various optimization techniques.
    15. 

  15.     </p></div><div class="chapter" title="Chapter 2. ISC DHCP 4.x"><div class="titlepage"><div><div><h2 class="title"><a name="dhcp4"></a>Chapter 2. ISC DHCP 4.x</h2></div></div></div><p>
    16. 

  16.       TODO: Write something about ISC DHCP4 here.
    17. 

  17.     </p></div><div class="chapter" title="Chapter 3. Kea"><div class="titlepage"><div><div><h2 class="title"><a name="kea"></a>Chapter 3. Kea</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#idp40176">3.1. Backend performance evaluation</a></span></dt><dt><span class="section"><a href="#mysql-backend">3.2. MySQL backend</a></span></dt><dd><dl><dt><span class="section"><a href="#idp64224">3.2.1. MySQL tweaks</a></span></dt></dl></dd><dt><span class="section"><a href="#sqlite-ubench">3.3. SQLite-ubench</a></span></dt><dd><dl><dt><span class="section"><a href="#sqlite-tweaks">3.3.1. SQLite tweaks</a></span></dt></dl></dd><dt><span class="section"><a href="#memfile-ubench">3.4. memfile-ubench</a></span></dt><dd><dl><dt><span class="section"><a href="#memfile-tweaks">3.4.1. memfile tweaks</a></span></dt></dl></dd><dt><span class="section"><a href="#idp104752">3.5. Basic performance measurements</a></span></dt><dt><span class="section"><a href="#idm38464">3.6. Optimized performance measurements</a></span></dt><dt><span class="section"><a href="#idp275344">3.7. Conclusions</a></span></dt><dt><span class="section"><a href="#idp281328">3.8. Possible further optimizations</a></span></dt></dl></div><p>
    18. 

  18. 

  19.     </p><div class="section" title="3.1. Backend performance evaluation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp40176"></a>3.1. Backend performance evaluation</h2></div></div></div><p>
    20. 

  20.         Kea will support several different database backends, using
    21. 

  21.         both popular databases (like MySQL or SQLite) and
    22. 

  22.         custom-developed solutions (such as an in-memory database).
    23. 

  23.         To aid in the choice of backend, the BIND 10
    24. 

  24.         source code features a set of performance microbenchmarks.
    25. 

  25.          Written in C/C++, these are small tools that simulate expected
    26. 

  26.         DHCP server behaviour and evaluate the performance of
    27. 

  27.         considered databases. As implemented, the benchmarks are not really
    28. 

  28.         simulating DHCP operation, but rather use set of primitives
    29. 

  29.         that can be used by a real server.  For this reason, they are called
    30. 

  30.         micro-benchmarks.
    31. 

  31.       </p><p>Although there are many operations and data types that
    32. 

  32.       server could store in a database, the most frequently used data
    33. 

  33.       type is lease information. Although the information held for IPv4
    34. 

  34.       and IPv6 leases differs slightly, it is expected that the performance
    35. 

  35.       differences will be minimal between IPv4 and IPv6 lease operations.
    36. 

  36.       Therefore each test uses the lease4 table (in which IPv4 leases are stored)
    37. 

  37.       for performance measurements.
    38. 

  38.       </p><p>All benchmarks are implemented as single threaded applications
    39. 

  39.       that take advantage of a single database connection.</p><p>
    40. 

  40.         Those benchmarks are stored in tests/tools/dhcp-ubench directory of the
    41. 

  41.         BIND 10 source tree. This directory contains simplified prototypes for
    42. 

  42.         the various database back-ends that are planned or considered as a
    43. 

  43.         possibly for BIND10 DHCP.  These benchmarks are expected to evolve into
    44. 

  44.         useful tools that will allow users to measure performance in their
    45. 

  45.         specific environment.
    46. 

  46.       </p><p>
    47. 

  47.       Currently the following benchmarks are implemented:
    48. 

  48.       </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>In memory + flat file</p></li><li class="listitem"><p>SQLite</p></li><li class="listitem"><p>MySQL</p></li></ul></div><p>
    49. 

  49.     </p><p>
    50. 

  50.       As the benchmarks require additional (sometimes heavy) dependencies, they
    51. 

  51.       are not built by default. Actually, their build system is completely
    52. 

  52.       separate from that of the rest of BIND 10.  It will be eventually merged
    53. 

  53.       with the main BIND 10 build system.
    54. 

  54.     </p><p>
    55. 

  55.       All benchmarks will follow the same pattern:
    56. 

  56.       </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Prepare operation (connect to a database, create a file etc.)</p></li><li class="listitem"><p>Measure timestamp 0</p></li><li class="listitem"><p>Commit new lease4 record (repeated N times)</p></li><li class="listitem"><p>Measure timestamp 1</p></li><li class="listitem"><p>Search for random lease4 record (repeated N times)</p></li><li class="listitem"><p>Measure timestamp 2</p></li><li class="listitem"><p>Update existing lease4 record (repeated N times)</p></li><li class="listitem"><p>Measure timestamp 3</p></li><li class="listitem"><p>Delete existing lease4 record (repeated N times)</p></li><li class="listitem"><p>Measure timestamp 4</p></li><li class="listitem"><p>Print out statistics, based on N and measured timestamps.</p></li></ol></div><p>
    57. 

  57. 

  58.       Although this approach does not attempt to simulate actual DHCP server
    59. 

  59.       operation that has mix of all steps, it answers the
    60. 

  60.       questions about basic database strengths and weak points. In particular
    61. 

  61.       it can show what is the impact of specific database optimizations, such as
    62. 

  62.       changing engine, optimizing for writes/reads etc.
    63. 

  63.     </p><p>
    64. 

  64.       The framework attempts to do the same amount of work for every
    65. 

  65.       backend thus allowing fair complarison between them.
    66. 

  66.     </p></div><div class="section" title="3.2. MySQL backend"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="mysql-backend"></a>3.2. MySQL backend</h2></div></div></div><p>The MySQL backend requires the MySQL client development libraries. It uses
    67. 

  67.       the mysql_config tool (similar to pkg-config) to discover required
    68. 

  68.       compilation and linking options. To install required packages on Ubuntu,
    69. 

  69.       use the following command:
    70. 

  70. 

  71.       </p><pre class="screen">$ <strong class="userinput"><code>sudo apt-get install mysql-client mysql-server libmysqlclient-dev</code></strong></pre><p>
    72. 

  72. 

  73.       Make sure that MySQL server is running. Make sure that you have your setup
    74. 

  74.       configured so there is a user that is able to modify used database.</p><p>Before running tests, you need to initialize your database. You can
    75. 

  75.       use mysql.schema script for that purpose.</p><p><span class="emphasis"><em>WARNING: It will drop existing
    76. 

  76.       Kea database. Do not run this on your production server. </em></span></p><p>Assuming your
    77. 

  77.       MySQL user is "kea", you can initialize your test database by:
    78. 

  78. 

  79.       </p><pre class="screen">$ <strong class="userinput"><code>mysql -u kea -p &lt; mysql.schema</code></strong></pre><p>
    80. 

  80.       </p><p>After the database is initialized, you are ready to run the test:
    81. 

  81.       </p><pre class="screen">$ <strong class="userinput"><code>./mysql_ubench</code></strong></pre><p>
    82. 

  82. 

  83.       or
    84. 

  84. 

  85.       </p><pre class="screen">$ <strong class="userinput"><code>./mysql_ubench &gt; results-mysql.txt</code></strong></pre><p>
    86. 

  86. 

  87.       Redirecting output to a file is important, because for each operation
    88. 

  88.       there is a single character printed to show progress. If you have a slow
    89. 

  89.       terminal, this may considerably affect test performance. On the other hand,
    90. 

  90.       printing something after each operation is required as poor database settings
    91. 

  91.       may slow down operations to around 20 per second. (The observant user is expected
    92. 

  92.       to note that the initial dots are printed too slowly and abort the test.)</p><p>Currently all default parameters are hardcoded. Default values can be
    93. 

  93.       overridden using command line switches. Although all benchmarks take
    94. 

  94.       the same list of parameters, some of them are specific to a given backend.
    95. 

  95.       To get a list of supported parameters, run the benchmark with the "-h" option:
    96. 

  96. 

  97.       </p><pre class="screen">$ <strong class="userinput"><code>./mysql_ubench -h</code></strong></pre><p>
    98. 

  98.       </p><p>Synchronous operation requires database backend to
    99. 

  99.       physically store changes to disk before proceeding. This
    100. 

  100.       property ensures that no data is lost in case of the server
    101. 

  101.       failure.  Unfortunately, it slows operation
    102. 

  102.       considerably. Asynchronous mode allows database to write data at
    103. 

  103.       a later time (usually controlled by the database engine on OS
    104. 

  104.       disk buffering mechanism).</p><div class="section" title="3.2.1. MySQL tweaks"><div class="titlepage"><div><div><h3 class="title"><a name="idp64224"></a>3.2.1. MySQL tweaks</h3></div></div></div><p>To modify the default mysql_ubench parameters, command line
    105. 

  105.         switches can be used. The currently supported switches are
    106. 

  106.         (default values specified in brackets):
    107. 

  107.         </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>-f name - name of the database ("kea")</p></li><li class="listitem"><p>-m hostname - name of the database host ("localhost")</p></li><li class="listitem"><p>-u user - MySQL username  ("root")</p></li><li class="listitem"><p>-p password - MySQL password ("secret")</p></li><li class="listitem"><p>-n num - number of iterations (100)</p></li><li class="listitem"><p>-s yes|no - should the operations be performed in a synchronous (yes)
    108. 

  108.           or asynchronous (no) manner (yes)</p></li><li class="listitem"><p>-v yes|no - verbose mode. Should the test print out progress? (yes)</p></li><li class="listitem"><p>-c yes|no - precompiled statements. Should the SQL statements be precompiled? (yes)</p></li></ol></div><p>
    109. 

  109.         </p><p>One parameter that has huge impact on performance is the choice of backend engine.
    110. 

  110.         You can get a list of engines of your MySQL implementation by using
    111. 

  111. 

  112.         </p><pre class="screen">&gt; <strong class="userinput"><code>show engines;</code></strong></pre><p>
    113. 

  113. 

  114.         in your mysql client. Two notable engines are MyISAM and InnoDB. mysql_ubench uses
    115. 

  115.         use MyISAM for synchronous mode and InnoDB for asynchronous. Please use
    116. 

  116.         '-s yes|no' to choose whether you want synchronous or asynchronous operations.</p><p>Another parameter that affects performance are precompiled statements.
    117. 

  117.         In a basic approach, the actual SQL query is passed as a text string that is
    118. 

  118.         then parsed by the database engine. Alternative is a so called precompiled
    119. 

  119.         statement. In this approach the SQL query is compiled an specific values are being
    120. 

  120.         bound to it. In the next iteration the query remains the same, only bound values
    121. 

  121.         are changing (e.g. searching for a different address). Usage of basic or precompiled
    122. 

  122.         statements is controlled with '-c no|yes'.</p></div></div><div class="section" title="3.3. SQLite-ubench"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sqlite-ubench"></a>3.3. SQLite-ubench</h2></div></div></div><p>The SQLite backend requires both the sqlite3 development and run-time packages. Their
    123. 

  123.       names may vary from system to system, but on Ubuntu 12.04 they are called
    124. 

  124.       sqlite3 libsqlite3-dev. To install them, use the following command:
    125. 

  125. 

  126.       </p><pre class="screen">&gt; <strong class="userinput"><code>sudo apt-get install sqlite3 libsqlite3-dev</code></strong></pre><p>
    127. 

  127. 

  128.       Before running the test the database has to be created. Use the following command for that:
    129. 

  129.       </p><pre class="screen">&gt; <strong class="userinput"><code>cat sqlite.schema | sqlite3 sqlite.db</code></strong></pre><p>
    130. 

  130. 

  131.       A new database called sqlite.db will be created. That is the default name used
    132. 

  132.       by sqlite_ubench test. If you prefer other name, make sure you update
    133. 

  133.       sqlite_ubench.cc accordingly.</p><p>Once the database is created, you can run tests:
    134. 

  134.       </p><pre class="screen">&gt; <strong class="userinput"><code>./sqlite_ubench</code></strong></pre><p>
    135. 

  135.       or
    136. 

  136.       </p><pre class="screen">&gt; <strong class="userinput"><code>./sqlite_ubench &gt; results-sqlite.txt</code></strong></pre><p>
    137. 

  137.       </p><div class="section" title="3.3.1. SQLite tweaks"><div class="titlepage"><div><div><h3 class="title"><a name="sqlite-tweaks"></a>3.3.1. SQLite tweaks</h3></div></div></div><p>To modify default sqlite_ubench parameters, command line
    138. 

  138.         switches can be used. The currently supported switches are
    139. 

  139.         (default values specified in brackets):
    140. 

  140.         </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>-f filename - name of the database file ("sqlite.db")</p></li><li class="listitem"><p>-n num - number of iterations (100)</p></li><li class="listitem"><p>-s yes|no - should the operations be performed in a synchronous (yes)
    141. 

  141.           or asynchronous (no) manner (yes)</p></li><li class="listitem"><p>-v yes|no - verbose mode. Should the test print out progress? (yes)</p></li><li class="listitem"><p>-c yes|no - precompiled statements. Should the SQL statements be precompiled? (yes)</p></li></ol></div><p>
    142. 

  142.         </p><p>SQLite can run in asynchronous or synchronous mode. This
    143. 

  143.         mode can be controlled by using "synchronous" parameter. It is set
    144. 

  144.         using the SQLite command:</p><p><span class="command"><strong>PRAGMA synchronous = ON|OFF</strong></span></p><p>Another tweakable feature is journal mode. It can be
    145. 

  145.         turned to several modes of operation. Its value can be
    146. 

  146.         modified in SQLite_uBenchmark::connect().  See
    147. 

  147.         http://www.sqlite.org/pragma.html#pragma_journal_mode for
    148. 

  148.         detailed explanantion.</p><p>sqlite_bench supports precompiled statements. Please use
    149. 

  149.         '-c no|yes' to define which should be used: basic SQL query (no) or
    150. 

  150.         precompiled statement (yes).</p></div></div><div class="section" title="3.4. memfile-ubench"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="memfile-ubench"></a>3.4. memfile-ubench</h2></div></div></div><p>The memfile backend is a
    151. 

  151.       custom backend that somewhat mimics operation of ISC DHCP4. It
    152. 

  152.       implements in-memory storage using standard C++ and boost
    153. 

  153.       mechanisms (std::map and boost::shared_ptr&lt;&gt;). All
    154. 

  154.       database changes are also written to a lease file, which is
    155. 

  155.       strictly write-only. This approach takes advantage of the fact
    156. 

  156.       that file append operation is faster than modifications introduced
    157. 

  157.       in the middle of the file (as it often requires moving all data
    158. 

  158.       after modified point, effectively requiring writing large parts of
    159. 

  159.       the whole file, not just changed fragment).</p><p>There are no preparatory steps required for memfile benchmark.
    160. 

  160.       The only requirement is the ability to create and write specified lease
    161. 

  161.       file (dhcpd.leases in the current directory). The tests can be run
    162. 

  162.       as follows:
    163. 

  163.       </p><pre class="screen">&gt; <strong class="userinput"><code>./memfile_ubench</code></strong></pre><p>
    164. 

  164.       or
    165. 

  165.       </p><pre class="screen">&gt; <strong class="userinput"><code>./memfile_ubench &gt; results-memfile.txt</code></strong></pre><p>
    166. 

  166.       </p><div class="section" title="3.4.1. memfile tweaks"><div class="titlepage"><div><div><h3 class="title"><a name="memfile-tweaks"></a>3.4.1. memfile tweaks</h3></div></div></div><p>To modify default memfile_ubench parameters, command line
    167. 

  167.         switches can be used. Currently supported switches are
    168. 

  168.         (default values specified in brackets):
    169. 

  169.         </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>-f filename - name of the database file ("dhcpd.leases")</p></li><li class="listitem"><p>-n num - number of iterations (100)</p></li><li class="listitem"><p>-s yes|no - should the operations be performend in a synchronous (yes)
    170. 

  170.           or asynchronous (no) manner (yes)</p></li><li class="listitem"><p>-v yes|no - verbose mode. Should the test print out progress? (yes)</p></li></ol></div><p>
    171. 

  171.         </p><p>memfile can run in asynchronous or synchronous mode. This
    172. 

  172.         mode can be controlled by using sync parameter. It uses
    173. 

  173.         fflush() and fsync() in synchronous mode to make sure that
    174. 

  174.         data is not buffered and physically stored on disk.</p></div></div><div class="section" title="3.5. Basic performance measurements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp104752"></a>3.5. Basic performance measurements</h2></div></div></div><p>This section contains sample results for backend performance measurements,
    175. 

  175.       taken using microbenchmarks. Tests were conducted on reasonably powerful machine:
    176. 

  176.       </p><pre class="screen">
    177. 

  177. CPU: Quad-core Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (8 logical cores)
    178. 

  178. HDD: 1,5TB Seagate Barracuda ST31500341AS 7200rpm, ext4 partition
    179. 

  179. OS: Ubuntu 12.04, running kernel 3.2.0-26-generic SMP x86_64
    180. 

  180. compiler: g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
    181. 

  181. MySQL version: 5.5.24
    182. 

  182. SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe77b41d959e9df13f8c9b5e</pre><p>
    183. 

  183.       </p><p>The benchmarks were run without using precompiled statements.
    184. 

  184.       The code was compiled with the -O0 flag (no code optimizations).
    185. 

  185.       Each run was executed once.</p><p>Two series of measures were made, synchronous and
    186. 

  186.       asynchronous. As those modes offer radically different
    187. 

  187.       performances, synchronous mode was conducted for one
    188. 

  188.       thousand repetitions and asynchronous mode was conducted for
    189. 

  189.       one hundred thousand repetitions.</p><div class="table"><a name="idp108384"></a><p class="title"><b>Table 3.1. Synchronous results (basic)</b></p><div class="table-contents"><table summary="Synchronous results (basic)" border="1"><colgroup><col align="center" class="Backend"><col align="center" class="Num"><col align="center" class="Create"><col align="center" class="Search"><col align="center" class="Update"><col align="center" class="Delete"></colgroup><thead><tr><th align="center">Backend</th><th align="center">Operations</th><th align="center">Create [s]</th><th align="center">Search [s]</th><th align="center">Update [s]</th><th align="center">Delete [s]</th><th align="center">Average [s]</th></tr></thead><tbody><tr><td align="center">MySQL</td><td align="center">1,000</td><td align="center">31.604</td><td align="center"> 0.117</td><td align="center">27.964</td><td align="center">27.695</td><td align="center">21.845</td></tr><tr><td align="center">SQLite</td><td align="center">1,000</td><td align="center">61.421</td><td align="center"> 0.033</td><td align="center">59.477</td><td align="center">56.034</td><td align="center">44.241</td></tr><tr><td align="center">memfile</td><td align="center">1,000</td><td align="center">38.224</td><td align="center"> 0.001</td><td align="center">38.041</td><td align="center">38.017</td><td align="center">28.571</td></tr></tbody></table></div></div><br class="table-break"><p>The following parameters were measured for asynchronous mode.
    190. 

  190.       MySQL and SQLite were run with one hundred thousand repetitions.</p><div class="table"><a name="idp129440"></a><p class="title"><b>Table 3.2. Asynchronous results (basic)</b></p><div class="table-contents"><table summary="Asynchronous results (basic)" border="1"><colgroup><col align="center" class="Backend"><col align="center" class="Num"><col align="center" class="Create"><col align="center" class="Search"><col align="center" class="Update"><col align="center" class="Delete"></colgroup><thead><tr><th align="center">Backend</th><th align="center">Operations</th><th align="center">Create [s]</th><th align="center">Search [s]</th><th align="center">Update [s]</th><th align="center">Delete [s]</th><th align="center">Average [s]</th></tr></thead><tbody><tr><td align="center">MySQL</td><td align="center">100,000</td><td align="center">10.585</td><td align="center">10.386</td><td align="center">10.062</td><td align="center"> 8.890</td><td align="center"> 9.981</td></tr><tr><td align="center">SQLite</td><td align="center">100,000</td><td align="center"> 3.710</td><td align="center"> 3.159</td><td align="center"> 2.865</td><td align="center"> 2.439</td><td align="center"> 3.044</td></tr><tr><td align="center">memfile</td><td align="center">100,000</td><td align="center"> 1.300</td><td align="center"> 0.039</td><td align="center"> 1.307</td><td align="center"> 1.278</td><td align="center"> 0.981</td></tr></tbody></table></div></div><br class="table-break"><p>The presented performance results can be converted into operations per second metrics.
    191. 

  191.       It should be noted that due to large differences between various operations (sometimes
    192. 

  192.       over three orders of magnitude), it is difficult to create a simple, readable chart with
    193. 

  193.       that data.</p><div class="table"><a name="tbl-basic-perf-results"></a><p class="title"><b>Table 3.3. Estimated basic performance</b></p><div class="table-contents"><table summary="Estimated basic performance" border="1"><colgroup><col align="center" class="Backend"><col align="center" class="Create"><col align="center" class="Search"><col align="center" class="Update"><col align="center" class="Delete"><col align="center" class="Average"></colgroup><thead><tr><th align="center">Backend</th><th align="center">Create [oper/s]</th><th align="center">Search [oper/s]</th><th align="center">Update [oper/s]</th><th align="center">Delete [oper/s]</th><th align="center">Average [oper/s]</th></tr></thead><tbody><tr><td align="center">MySQL (async)</td><td align="center">9447.47</td><td align="center">9627.97</td><td align="center">9938.00</td><td align="center">11248.34</td><td align="center">10065.45</td></tr><tr><td align="center">SQLite (async)</td><td align="center">26951.59</td><td align="center">31654.29</td><td align="center">34899.70</td><td align="center">40993.59</td><td align="center">33624.79</td></tr><tr><td align="center">memfile (async)</td><td align="center">76944.27</td><td align="center">2542588.35</td><td align="center">76504.54</td><td align="center">78269.25</td><td align="center">693576.60</td></tr><tr><td align="center">MySQL (sync)</td><td align="center">31.64</td><td align="center">8575.45</td><td align="center">35.76</td><td align="center">36.11</td><td align="center">2169.74</td></tr><tr><td align="center">SQLite (sync)</td><td align="center">16.28</td><td align="center">20045.37</td><td align="center">16.81</td><td align="center">17.85</td><td align="center">7524.08</td></tr><tr><td align="center">memfile (sync)</td><td align="center">26.16</td><td align="center">1223990.21</td><td align="center">26.29</td><td align="center">26.30</td><td align="center">306017.24</td></tr></tbody></table></div></div><br class="table-break"><div class="mediaobject"><img src="performance-results-graph1.png"><div class="caption"><p>Graphical representation of the basic performance results
    194. 

  194.           presented in table <a class="xref" href="#tbl-basic-perf-results" title="Table 3.3. Estimated basic performance">Table 3.3, &#8220;Estimated basic performance&#8221;</a>.</p></div></div></div><div class="section" title="3.6. Optimized performance measurements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idm38464"></a>3.6. Optimized performance measurements</h2></div></div></div><p>This section contains sample results for backend performance measurements,
    195. 

  195.       taken using microbenchmarks. Tests were conducted on reasonably powerful machine:
    196. 

  196.       </p><pre class="screen">
    197. 

  197. CPU: Quad-core Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (8 logical cores)
    198. 

  198. HDD: 1,5TB Seagate Barracuda ST31500341AS 7200rpm, ext4 partition
    199. 

  199. OS: Ubuntu 12.04, running kernel 3.2.0-26-generic SMP x86_64
    200. 

  200. compiler: g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
    201. 

  201. MySQL version: 5.5.24
    202. 

  202. SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe77b41d959e9df13f8c9b5e</pre><p>
    203. 

  203.       </p><p>The benchmarks were run with precompiled statements enabled.
    204. 

  204.       The code was compiled with the -Ofast flag (optimize compilation for speed).
    205. 

  205.       Each run was repeated three times and measured values were averaged.</p><p>Again the benchmarks were run in two series, synchronous and
    206. 

  206.       asynchronous. As those modes offer radically different
    207. 

  207.       performances, synchronous mode was conducted for one
    208. 

  208.       thousand repetitions and asynchronous mode was conducted for
    209. 

  209.       one hundred thousand repetitions.</p><div class="table"><a name="idp204944"></a><p class="title"><b>Table 3.4. Synchronous results (optimized)</b></p><div class="table-contents"><table summary="Synchronous results (optimized)" border="1"><colgroup><col align="center" class="Backend"><col align="center" class="Num"><col align="center" class="Create"><col align="center" class="Search"><col align="center" class="Update"><col align="center" class="Delete"></colgroup><thead><tr><th align="center">Backend</th><th align="center">Operations</th><th align="center">Create [s]</th><th align="center">Search [s]</th><th align="center">Update [s]</th><th align="center">Delete [s]</th><th align="center">Average [s]</th></tr></thead><tbody><tr><td align="center">MySQL</td><td align="center">1,000</td><td align="center">27.887</td><td align="center"> 0.106</td><td align="center">28.223</td><td align="center">27.696</td><td align="center">20.978</td></tr><tr><td align="center">SQLite</td><td align="center">1,000</td><td align="center">61.299</td><td align="center"> 0.015</td><td align="center">59.648</td><td align="center">61.098</td><td align="center">45.626</td></tr><tr><td align="center">memfile</td><td align="center">1,000</td><td align="center">39.564</td><td align="center"> 0.001</td><td align="center">39.543</td><td align="center">39.326</td><td align="center">29.608</td></tr></tbody></table></div></div><br class="table-break"><p>The following parameters were measured for asynchronous mode.
    210. 

  210.       MySQL and SQLite were run with one hundred thousand repetitions.</p><div class="table"><a name="idp225424"></a><p class="title"><b>Table 3.5. Asynchronous results (optimized)</b></p><div class="table-contents"><table summary="Asynchronous results (optimized)" border="1"><colgroup><col align="center" class="Backend"><col align="center" class="Num"><col align="center" class="Create"><col align="center" class="Search"><col align="center" class="Update"><col align="center" class="Delete"></colgroup><thead><tr><th align="center">Backend</th><th align="center">Operations</th><th align="center">Create [s]</th><th align="center">Search [s]</th><th align="center">Update [s]</th><th align="center">Delete [s]</th><th align="center">Average [s]</th></tr></thead><tbody><tr><td align="center">MySQL</td><td align="center">100,000</td><td align="center">8.507</td><td align="center">9.698</td><td align="center">7.785</td><td align="center">8.326</td><td align="center">8.579</td></tr><tr><td align="center">SQLite</td><td align="center">100,000</td><td align="center"> 1.562</td><td align="center"> 0.949</td><td align="center"> 1.513</td><td align="center"> 1.502</td><td align="center"> 1.382</td></tr><tr><td align="center">memfile</td><td align="center">100,000</td><td align="center">1.302</td><td align="center">0.038</td><td align="center">1.306</td><td align="center">1.263</td><td align="center">0.977</td></tr></tbody></table></div></div><br class="table-break"><p>The presented performance results can be converted into operations per second metrics.
    211. 

  211.       It should be noted that due to large differences between various operations (sometime
    212. 

  212.       over three orders of magnitude), it is difficult to create a simple, readable chart with
    213. 

  213.       the data.</p><div class="table"><a name="tbl-optim-perf-results"></a><p class="title"><b>Table 3.6. Estimated optimized performance</b></p><div class="table-contents"><table summary="Estimated optimized performance" border="1"><colgroup><col align="center" class="Backend"><col align="center" class="Create"><col align="center" class="Search"><col align="center" class="Update"><col align="center" class="Delete"><col align="center" class="Average"></colgroup><thead><tr><th align="center">Backend</th><th align="center">Create [oper/s]</th><th align="center">Search [oper/s]</th><th align="center">Update [oper/s]</th><th align="center">Delete [oper/s]</th><th align="center">Average [oper/s]</th></tr></thead><tbody><tr><td align="center">MySQL (async)</td><td align="center">11754.84</td><td align="center">10311.34</td><td align="center">12845.35</td><td align="center">12010.24</td><td align="center">11730.44</td></tr><tr><td align="center">SQLite (async)</td><td align="center">64005.90</td><td align="center">105391.29</td><td align="center">66075.51</td><td align="center">66566.43</td><td align="center">75509.78</td></tr><tr><td align="center">memfile (async)</td><td align="center">76832.16</td><td align="center">2636018.56</td><td align="center">76542.50</td><td align="center">79188.81</td><td align="center">717145.51</td></tr><tr><td align="center">MySQL (sync)</td><td align="center">35.86</td><td align="center">9461.10</td><td align="center">35.43</td><td align="center">36.11</td><td align="center">2392.12</td></tr><tr><td align="center">SQLite (sync)</td><td align="center">16.31</td><td align="center">67036.11</td><td align="center">16.76</td><td align="center">16.37</td><td align="center">16771.39</td></tr><tr><td align="center">memfile (sync)</td><td align="center">25.28</td><td align="center">3460207.61</td><td align="center">25.29</td><td align="center">25.43</td><td align="center">865070.90</td></tr></tbody></table></div></div><br class="table-break"><div class="mediaobject"><img src="performance-results-graph2.png" alt="Optimized performance measurements"><div class="caption"><p>Graphical representation of the optimized performance
    214. 

  214.           results presented in table <a class="xref" href="#tbl-optim-perf-results" title="Table 3.6. Estimated optimized performance">Table 3.6, &#8220;Estimated optimized performance&#8221;</a>.</p></div></div></div><div class="section" title="3.7. Conclusions"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp275344"></a>3.7. Conclusions</h2></div></div></div><p>
    215. 

  215.         Improvements gained by introducing support for precompiled
    216. 

  216.         statements in MySQL is somewhat disappointing - between 6 and
    217. 

  217.         29%.  On the other hand, the improvement in SQLite is
    218. 

  218.         surprisingly high - the efficiency is more than doubled.
    219. 

  219.       </p><p>
    220. 

  220.         Compiled statements do not have any measureable impact on
    221. 

  221.         synchronous operations. That is as expected, because the major
    222. 

  222.         bottleneck is the disk performance.
    223. 

  223.       </p><p>
    224. 

  224.         Compilation flags yield surprisingly high improvements for C++
    225. 

  225.         STL code. The memfile backend is in some operations is almost
    226. 

  226.         twice as fast.
    227. 

  227.       </p><p>
    228. 

  228.         If synchronous operation is required, the current performance
    229. 

  229.         results are likely to be deemed inadequate. The limiting
    230. 

  230.         factor here is a disk access time. Even migrating to high
    231. 

  231.         performance 15,000 rpm disk is expected to only roughly double
    232. 

  232.         number of leases per second, compared to the current results.
    233. 

  233.         The reason is that to write a file to disk, at least two disk
    234. 

  234.         sector writes
    235. 

  235.         are required: the new content and i-node modification of the
    236. 

  236.         file. The easiest way to boost synchronous performance is to
    237. 

  237.         switch to SSD disks. Memory-backed RAM disks are also a viable
    238. 

  238.         solution. However, care should be taken to properly engineer
    239. 

  239.         backup strategy for such RAM disks.
    240. 

  240.       </p><p>
    241. 

  241.         While the custom made backend (memfile) provides the best
    242. 

  242.         perfomance, it carries over all the limitations existing in
    243. 

  243.         the ISC DHCP4 code: there are no external tools to query or
    244. 

  244.         change database, the maintenance requires deep knowledge etc.
    245. 

  245.         Those flaws are not shared by usage of a proper database
    246. 

  246.         backend, like MySQL and SQLite. They both offer third party
    247. 

  247.         tools for administrative tasks, they are well documented and
    248. 

  248.         maintained. However, SQLite support for concurrent access is
    249. 

  249.         limiting in certain cases. Since all three investigated
    250. 

  250.         backends more than meet expected performance results, it is
    251. 

  251.         recommended to use MySQL as a first concrete database backend.
    252. 

  252.         Should this choice be rejected for any reason, the second
    253. 

  253.         recommended choice is SQLite.
    254. 

  254.       </p><p>
    255. 

  255.         It should be emphaisized that obtained measurements indicate
    256. 

  256.         only database performance and they cannot be directly
    257. 

  257.         translated to expected leases per second or queries per second
    258. 

  258.         performance by an actual server. The DHCP server must do much
    259. 

  259.         more than just query the database to properly process client's
    260. 

  260.         message. The provided results should be considered as only rough
    261. 

  261.         estimates. They can also be used for relative comparisons
    262. 

  262.         between backends.
    263. 

  263.       </p></div><div class="section" title="3.8. Possible further optimizations"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp281328"></a>3.8. Possible further optimizations</h2></div></div></div><p>
    264. 

  264.         For basic measurements the code was compiled with -g -O0
    265. 

  265.         flags. For optimized measurements the benchmarking code was
    266. 

  266.         compiled with -Ofast (optimize for speed). In both cases, the
    267. 

  267.         same backend (MySQL or SQLite) library was used. It may be
    268. 

  268.         useful to recompile the libraries (or the whole server in case
    269. 

  269.         of MySQL) with -Ofast.
    270. 

  270.       </p><p>
    271. 

  271.         There are many MySQL parameters that various sources recommend
    272. 

  272.         to improve performance. They were not investigated further.
    273. 

  273.       </p><p>
    274. 

  274.         Currently all operations are conducted on one by one
    275. 

  275.         basis. Each operation is treated as a separate
    276. 

  276.         transaction. Grouping N operations together will potentially
    277. 

  277.         bring almost N fold increase in synchronous operations. Such a
    278. 

  278.         feature is present in ISC DHCP4 and is called cache-threshold.
    279. 

  279.         Extension for this benchmark in this regard should be
    280. 

  280.         considered.  That affects only write operations (insert,
    281. 

  281.         update and delete). Read operations (search) are expected to
    282. 

  282.         be barely affected.
    283. 

  283.       </p><p>
    284. 

  284.         Multi-threaded or multi-process benchmark may be considered in
    285. 

  285.         the future. It may be somewhat difficult as only some backends
    286. 

  286.         support concurrent access.
    287. 

  287.       </p></div></div><div class="chapter" title="Chapter 4. perfdhcp"><div class="titlepage"><div><div><h2 class="title"><a name="perfdhcp"></a>Chapter 4. perfdhcp</h2></div></div></div><p>
    288. 

  288.       TODO: Write something about perfdhcp here.
    289. 

  289.     </p></div></div></body></html>
    290.