Browse Source

[2143] Minor corrections in DHCP Performance Guide after review.

Tomek Mrugalski 12 years ago
parent
commit
0ed7d2f838

File diff suppressed because it is too large
+ 41 - 48
tests/tools/dhcp-ubench/dhcp-perf-guide.html


+ 59 - 44
tests/tools/dhcp-ubench/dhcp-perf-guide.xml

@@ -120,12 +120,12 @@
       that take advantage of a single database connection.</para>
       that take advantage of a single database connection.</para>
 
 
       <para>
       <para>
-        Those benchmarks are stored in tests/tools/dhcp-ubench
-        directory of the BIND 10 source tree. This directory contains simplified prototypes for
+        Those benchmarks are stored in tests/tools/dhcp-ubench directory of the
+        BIND 10 source tree. This directory contains simplified prototypes for
         the various database back-ends that are planned or considered as a
         the various database back-ends that are planned or considered as a
-        possibly for BIND10 DHCP.  Athough trivial now, the benchmarks are
-        expected to evolve into useful tools that will allow users to
-        measure performance in their specific environment.
+        possibly for BIND10 DHCP.  These benchmarks are expected to evolve into
+        useful tools that will allow users to measure performance in their
+        specific environment.
       </para>
       </para>
 
 
     <para>
     <para>
@@ -138,11 +138,10 @@
     </para>
     </para>
 
 
     <para>
     <para>
-      As the benchmarks require additional (sometimes heavy) dependencies, they are not
-      built by default. Actually, their build system is completely separate from that
-      of the rest of BIND 10.
-      It is anticipated that they will be eventually merged into the rest of BIND 10, but
-      that is a low priority for now.
+      As the benchmarks require additional (sometimes heavy) dependencies, they
+      are not built by default. Actually, their build system is completely
+      separate from that of the rest of BIND 10.  It will be eventually merged
+      with the main BIND 10 build system.
     </para>
     </para>
 
 
     <para>
     <para>
@@ -188,10 +187,10 @@
 
 
       <para>Before running tests, you need to initialize your database. You can
       <para>Before running tests, you need to initialize your database. You can
       use mysql.schema script for that purpose.</para>
       use mysql.schema script for that purpose.</para>
-      
+
       <para><emphasis>WARNING: It will drop existing
       <para><emphasis>WARNING: It will drop existing
       Kea database. Do not run this on your production server. </emphasis></para>
       Kea database. Do not run this on your production server. </emphasis></para>
-      
+
       <para>Assuming your
       <para>Assuming your
       MySQL user is "kea", you can initialize your test database by:
       MySQL user is "kea", you can initialize your test database by:
 
 
@@ -217,24 +216,7 @@
       the same list of parameters, some of them are specific to a given backend.
       the same list of parameters, some of them are specific to a given backend.
       To get a list of supported parameters, run the benchmark with the "-h" option:
       To get a list of supported parameters, run the benchmark with the "-h" option:
 
 
-      <screen>$ <userinput>./mysql_ubench -h</userinput>
-This is a benchmark designed to measure expected performance
-of several backends. This particular version identifies itself
-as following:
-MySQL client version is 5.5.24
-
-Possible command-line parameters:
- -h - help (you are reading this)
- -m hostname - specifies MySQL server to connect (MySQL backend only)
- -u username - specifies MySQL user name (MySQL backend only)
- -p password - specifies MySQL passwod (MySQL backend only)
- -f name - database or filename (MySQL, SQLite and memfile)
- -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)
-</screen>
-
+      <screen>$ <userinput>./mysql_ubench -h</userinput></screen>
       </para>
       </para>
 
 
       <para>Synchronous operation requires database backend to
       <para>Synchronous operation requires database backend to
@@ -248,6 +230,23 @@ Possible command-line parameters:
       <section>
       <section>
         <title>MySQL tweaks</title>
         <title>MySQL tweaks</title>
 
 
+        <para>To modify the default mysql_ubench parameters, command line
+        switches can be used. The currently supported switches are
+        (default values specified in brackets):
+        <orderedlist>
+          <listitem><para>-f name - name of the database ("kea")</para></listitem>
+          <listitem><para>-m hostname - name of the database host ("localhost")</para></listitem>
+          <listitem><para>-u user - MySQL username  ("root")</para></listitem>
+          <listitem><para>-p password - MySQL password ("secret")</para></listitem>
+          <listitem><para>-n num - number of iterations (100)</para></listitem>
+          <listitem><para>-s yes|no - should the operations be performed in a synchronous (yes)
+          or asynchronous (no) manner (yes)</para></listitem>
+          <listitem><para>-v yes|no - verbose mode. Should the test print out progress? (yes)</para></listitem>
+          <listitem><para>-c yes|no - precompiled statements. Should the SQL statements be precompiled? (yes)</para></listitem>
+        </orderedlist>
+        </para>
+
+
         <para>One parameter that has huge impact on performance is the choice of backend engine.
         <para>One parameter that has huge impact on performance is the choice of backend engine.
         You can get a list of engines of your MySQL implementation by using
         You can get a list of engines of your MySQL implementation by using
 
 
@@ -300,14 +299,14 @@ Possible command-line parameters:
           <listitem><para>-s yes|no - should the operations be performed in a synchronous (yes)
           <listitem><para>-s yes|no - should the operations be performed in a synchronous (yes)
           or asynchronous (no) manner (yes)</para></listitem>
           or asynchronous (no) manner (yes)</para></listitem>
           <listitem><para>-v yes|no - verbose mode. Should the test print out progress? (yes)</para></listitem>
           <listitem><para>-v yes|no - verbose mode. Should the test print out progress? (yes)</para></listitem>
-          <listitem><para>-c yes|no - precompiled statements. Should the SQL statements be precompiled?</para></listitem>
+          <listitem><para>-c yes|no - precompiled statements. Should the SQL statements be precompiled? (yes)</para></listitem>
         </orderedlist>
         </orderedlist>
         </para>
         </para>
 
 
         <para>SQLite can run in asynchronous or synchronous mode. This
         <para>SQLite can run in asynchronous or synchronous mode. This
         mode can be controlled by using "synchronous" parameter. It is set
         mode can be controlled by using "synchronous" parameter. It is set
         using the SQLite command:</para>
         using the SQLite command:</para>
-        
+
         <para><command>PRAGMA synchronous = ON|OFF</command></para>
         <para><command>PRAGMA synchronous = ON|OFF</command></para>
 
 
         <para>Another tweakable feature is journal mode. It can be
         <para>Another tweakable feature is journal mode. It can be
@@ -334,6 +333,15 @@ Possible command-line parameters:
       after modified point, effectively requiring writing large parts of
       after modified point, effectively requiring writing large parts of
       the whole file, not just changed fragment).</para>
       the whole file, not just changed fragment).</para>
 
 
+      <para>There are no preparatory steps required for memfile benchmark.
+      The only requirement is the ability to create and write specified lease
+      file (dhcpd.leases in the current directory). The tests can be run
+      as follows:
+      <screen>&gt; <userinput>./memfile_ubench</userinput></screen>
+      or
+      <screen>&gt; <userinput>./memfile_ubench > results-memfile.txt</userinput></screen>
+      </para>
+
       <section id="memfile-tweaks">
       <section id="memfile-tweaks">
         <title>memfile tweaks</title>
         <title>memfile tweaks</title>
         <para>To modify default memfile_ubench parameters, command line
         <para>To modify default memfile_ubench parameters, command line
@@ -435,8 +443,7 @@ SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe7
       </table>
       </table>
 
 
       <para>The following parameters were measured for asynchronous mode.
       <para>The following parameters were measured for asynchronous mode.
-      MySQL and SQLite were run with one hundred thousand repetitions. Memfile
-      was run for one million repetitions due to its much higher performance.</para>
+      MySQL and SQLite were run with one hundred thousand repetitions.</para>
 
 
       <!-- raw results async -->
       <!-- raw results async -->
       <table><title>Asynchronous results (basic)</title>
       <table><title>Asynchronous results (basic)</title>
@@ -482,7 +489,7 @@ SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe7
 
 
           <row>
           <row>
             <entry>memfile</entry>
             <entry>memfile</entry>
-            <entry>1,000,000</entry>
+            <entry>100,000</entry>
             <entry> 1.300</entry>
             <entry> 1.300</entry>
             <entry> 0.039</entry>
             <entry> 0.039</entry>
             <entry> 1.307</entry>
             <entry> 1.307</entry>
@@ -577,13 +584,21 @@ SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe7
       </tgroup>
       </tgroup>
       </table>
       </table>
 
 
+      <!-- that is obsolete approach that is going to be removed in docbook 5.0.
+      Its only advantage is that it actually works with docbook2pdf -->
+      <!--
+      <figure>
+        <title>Graphical representation of the basic performance
+        results presented in table <xref linkend="tbl-basic-perf-results" />.</title>
+        <graphic scale="100" fileref="performance-results-graph1.png" />
+      </figure>-->
+
+      <!-- this works great for HTML export, but is silently ignored by docbook2pdf
+      and docbook2ps tools. -->
       <mediaobject>
       <mediaobject>
         <imageobject>
         <imageobject>
-          <imagedata fileref="performance-results-graph1.png" format="PNG"/>
+          <imagedata fileref="performance-results-graph1.png" format="PNG" />
         </imageobject>
         </imageobject>
-        <textobject>
-          <phrase>Basic performance measurements</phrase>
-        </textobject>
         <caption>
         <caption>
           <para>Graphical representation of the basic performance results
           <para>Graphical representation of the basic performance results
           presented in table <xref linkend="tbl-basic-perf-results" />.</para>
           presented in table <xref linkend="tbl-basic-perf-results" />.</para>
@@ -672,8 +687,7 @@ SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe7
       </table>
       </table>
 
 
       <para>The following parameters were measured for asynchronous mode.
       <para>The following parameters were measured for asynchronous mode.
-      MySQL and SQLite were run with one hundred thousand repetitions. Memfile
-      was run for one million repetitions due to its much higher performance.</para>
+      MySQL and SQLite were run with one hundred thousand repetitions.</para>
 
 
       <!-- raw results async -->
       <!-- raw results async -->
       <table><title>Asynchronous results (optimized)</title>
       <table><title>Asynchronous results (optimized)</title>
@@ -719,7 +733,7 @@ SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe7
 
 
           <row>
           <row>
             <entry>memfile</entry>
             <entry>memfile</entry>
-            <entry>1,000,000</entry>
+            <entry>100,000</entry>
             <entry>1.302</entry>
             <entry>1.302</entry>
             <entry>0.038</entry>
             <entry>0.038</entry>
             <entry>1.306</entry>
             <entry>1.306</entry>
@@ -855,12 +869,13 @@ SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe7
         factor here is a disk access time. Even migrating to high
         factor here is a disk access time. Even migrating to high
         performance 15,000 rpm disk is expected to only roughly double
         performance 15,000 rpm disk is expected to only roughly double
         number of leases per second, compared to the current results.
         number of leases per second, compared to the current results.
-        The reason is that to write a file to disk, at least two writes
+        The reason is that to write a file to disk, at least two disk
+        sector writes
         are required: the new content and i-node modification of the
         are required: the new content and i-node modification of the
         file. The easiest way to boost synchronous performance is to
         file. The easiest way to boost synchronous performance is to
         switch to SSD disks. Memory-backed RAM disks are also a viable
         switch to SSD disks. Memory-backed RAM disks are also a viable
         solution. However, care should be taken to properly engineer
         solution. However, care should be taken to properly engineer
-        backup strategy for RAM disks.
+        backup strategy for such RAM disks.
       </para>
       </para>
 
 
       <para>
       <para>