Author: jstephens
Date: 2008-03-12 18:25:47 +0100 (Wed, 12 Mar 2008)
New Revision: 10211
Log:
Cleared a couple of TODOs
Got rid of some ancient (4+ years old) performance figures
Modified:
trunk/refman-4.1/mysql-cluster-interconnects.xml
trunk/refman-5.0/mysql-cluster-interconnects.xml
trunk/refman-5.1/mysql-cluster-interconnects.xml
trunk/refman-6.0/mysql-cluster-interconnects.xml
Modified: trunk/refman-4.1/mysql-cluster-interconnects.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster-interconnects.xml 2008-03-12 15:30:43 UTC (rev 10210)
+++ trunk/refman-4.1/mysql-cluster-interconnects.xml 2008-03-12 17:25:47 UTC (rev 10211)
Changed blocks: 2, Lines Added: 11, Lines Deleted: 112; 5903 bytes
@@ -698,110 +698,13 @@
</itemizedlist>
<para>
- To check the base performance of these access methods, we have
- developed a set of benchmarks. One such benchmark,
- <command>testReadPerf</command>, tests simple and batched primary
- and unique key accesses. This benchmark also measures the setup
- cost of range scans by issuing scans returning a single record.
- There is also a variant of this benchmark which uses a range scan
- to fetch a batch of records.
- </para>
-
- <para>
- In this way, we can determine the cost of both a single key access
- and a single record scan access, as well as measure the impact of
- the communication media used, on base access methods.
- </para>
-
- <remark role="todo">
- How current are these figures? [js]
- </remark>
-
- <para>
- In our tests, we ran the base benchmarks for both a normal
- transporter using TCP/IP sockets and a similar setup using SCI
- sockets. The figures reported in the following table are for small
- accesses of 20 records per access. The difference between serial
- and batched access decreases by a factor of 3 to 4 when using 2KB
- records instead. SCI Sockets were not tested with 2KB records.
- Tests were performed on a cluster with 2 data nodes running on 2
- dual-CPU machines equipped with AMD MP1900+ processors.
- </para>
-
- <informaltable>
- <tgroup cols="3">
- <colspec colwidth="33*"/>
- <colspec colwidth="34*"/>
- <colspec colwidth="33*"/>
- <tbody>
- <row>
- <entry><emphasis role="bold">Access Type</emphasis></entry>
- <entry><emphasis role="bold">TCP/IP Sockets</emphasis></entry>
- <entry><emphasis role="bold">SCI Socket</emphasis></entry>
- </row>
- <row>
- <entry>Serial pk access</entry>
- <entry>400 microseconds</entry>
- <entry>160 microseconds</entry>
- </row>
- <row>
- <entry>Batched pk access</entry>
- <entry>28 microseconds</entry>
- <entry>22 microseconds</entry>
- </row>
- <row>
- <entry>Serial uk access</entry>
- <entry>500 microseconds</entry>
- <entry>250 microseconds</entry>
- </row>
- <row>
- <entry>Batched uk access</entry>
- <entry>70 microseconds</entry>
- <entry>36 microseconds</entry>
- </row>
- <row>
- <entry>Indexed eq-bound</entry>
- <entry>1250 microseconds</entry>
- <entry>750 microseconds</entry>
- </row>
- <row>
- <entry>Index range</entry>
- <entry>24 microseconds</entry>
- <entry>12 microseconds</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>SCI, performance <foreignphrase>vs</foreignphrase> TCP/IP</secondary>
- </indexterm>
-
- <para>
- We also performed another set of tests to check the performance of
- SCI Sockets <foreignphrase>vis-à-vis</foreignphrase> that of the
- SCI transporter, and both of these as compared with the TCP/IP
- transporter. All these tests used primary key accesses either
- serially and multi-threaded, or multi-threaded and batched.
- </para>
-
- <para>
- The tests showed that SCI sockets were about 100% faster than
- TCP/IP. The SCI transporter was faster in most cases compared to
- SCI sockets. One notable case occurred with many threads in the
- test program, which showed that the SCI transporter did not
- perform very well when used for the <command>mysqld</command>
- process.
- </para>
-
- <para>
- Our overall conclusion was that, for most benchmarks, using SCI
- sockets improves performance by approximately 100% over TCP/IP,
- except in rare instances when communication performance is not an
- issue. This can occur when scan filters make up most of processing
- time or when very large batches of primary key accesses are
- achieved. In that case, the CPU processing in the
+ With benchmarks developed internally by MySQL for testing simple
+ and batched primary and unique key accesses, we have found that
+ using SCI sockets improves performance by approximately 100% over
+ TCP/IP, except in rare instances when communication performance is
+ not an issue. This can occur when scan filters make up most of
+ processing time or when very large batches of primary key accesses
+ are achieved. In that case, the CPU processing in the
<command>ndbd</command> processes becomes a fairly large part of
the overhead.
</para>
@@ -823,17 +726,13 @@
as well.)
</para>
- <remark role="todo">
- Provide links to these? (Not high priority item.) [js]
- </remark>
-
<para>
There are several other optimized socket implementations for
computer clusters, including Myrinet, Gigabit Ethernet, Infiniband
- and the VIA interface. We have tested MySQL Cluster so far only
- with SCI sockets. See <xref linkend="mysql-cluster-sci-sockets"/>
- for information on how to set up SCI sockets using ordinary TCP/IP
- for MySQL Cluster.
+ and the VIA interface. However, we have tested MySQL Cluster so
+ far only with SCI sockets. See
+ <xref linkend="mysql-cluster-sci-sockets"/>, for information on
+ how to set up SCI sockets using ordinary TCP/IP for MySQL Cluster.
</para>
</section>
Modified: trunk/refman-5.0/mysql-cluster-interconnects.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-interconnects.xml 2008-03-12 15:30:43 UTC (rev 10210)
+++ trunk/refman-5.0/mysql-cluster-interconnects.xml 2008-03-12 17:25:47 UTC (rev 10211)
Changed blocks: 2, Lines Added: 11, Lines Deleted: 112; 5903 bytes
@@ -712,110 +712,13 @@
</itemizedlist>
<para>
- To check the base performance of these access methods, we have
- developed a set of benchmarks. One such benchmark,
- <command>testReadPerf</command>, tests simple and batched primary
- and unique key accesses. This benchmark also measures the setup
- cost of range scans by issuing scans returning a single record.
- There is also a variant of this benchmark which uses a range scan
- to fetch a batch of records.
- </para>
-
- <para>
- In this way, we can determine the cost of both a single key access
- and a single record scan access, as well as measure the impact of
- the communication media used, on base access methods.
- </para>
-
- <remark role="todo">
- How current are these figures? [js]
- </remark>
-
- <para>
- In our tests, we ran the base benchmarks for both a normal
- transporter using TCP/IP sockets and a similar setup using SCI
- sockets. The figures reported in the following table are for small
- accesses of 20 records per access. The difference between serial
- and batched access decreases by a factor of 3 to 4 when using 2KB
- records instead. SCI Sockets were not tested with 2KB records.
- Tests were performed on a cluster with 2 data nodes running on 2
- dual-CPU machines equipped with AMD MP1900+ processors.
- </para>
-
- <informaltable>
- <tgroup cols="3">
- <colspec colwidth="33*"/>
- <colspec colwidth="34*"/>
- <colspec colwidth="33*"/>
- <tbody>
- <row>
- <entry><emphasis role="bold">Access Type</emphasis></entry>
- <entry><emphasis role="bold">TCP/IP Sockets</emphasis></entry>
- <entry><emphasis role="bold">SCI Socket</emphasis></entry>
- </row>
- <row>
- <entry>Serial pk access</entry>
- <entry>400 microseconds</entry>
- <entry>160 microseconds</entry>
- </row>
- <row>
- <entry>Batched pk access</entry>
- <entry>28 microseconds</entry>
- <entry>22 microseconds</entry>
- </row>
- <row>
- <entry>Serial uk access</entry>
- <entry>500 microseconds</entry>
- <entry>250 microseconds</entry>
- </row>
- <row>
- <entry>Batched uk access</entry>
- <entry>70 microseconds</entry>
- <entry>36 microseconds</entry>
- </row>
- <row>
- <entry>Indexed eq-bound</entry>
- <entry>1250 microseconds</entry>
- <entry>750 microseconds</entry>
- </row>
- <row>
- <entry>Index range</entry>
- <entry>24 microseconds</entry>
- <entry>12 microseconds</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>SCI, performance <foreignphrase>vs</foreignphrase> TCP/IP</secondary>
- </indexterm>
-
- <para>
- We also performed another set of tests to check the performance of
- SCI Sockets <foreignphrase>vis-à-vis</foreignphrase> that of the
- SCI transporter, and both of these as compared with the TCP/IP
- transporter. All these tests used primary key accesses either
- serially and multi-threaded, or multi-threaded and batched.
- </para>
-
- <para>
- The tests showed that SCI sockets were about 100% faster than
- TCP/IP. The SCI transporter was faster in most cases compared to
- SCI sockets. One notable case occurred with many threads in the
- test program, which showed that the SCI transporter did not
- perform very well when used for the <command>mysqld</command>
- process.
- </para>
-
- <para>
- Our overall conclusion was that, for most benchmarks, using SCI
- sockets improves performance by approximately 100% over TCP/IP,
- except in rare instances when communication performance is not an
- issue. This can occur when scan filters make up most of processing
- time or when very large batches of primary key accesses are
- achieved. In that case, the CPU processing in the
+ With benchmarks developed internally by MySQL for testing simple
+ and batched primary and unique key accesses, we have found that
+ using SCI sockets improves performance by approximately 100% over
+ TCP/IP, except in rare instances when communication performance is
+ not an issue. This can occur when scan filters make up most of
+ processing time or when very large batches of primary key accesses
+ are achieved. In that case, the CPU processing in the
<command>ndbd</command> processes becomes a fairly large part of
the overhead.
</para>
@@ -837,17 +740,13 @@
as well.)
</para>
- <remark role="todo">
- Provide links to these? (Not high priority item.) [js]
- </remark>
-
<para>
There are several other optimized socket implementations for
computer clusters, including Myrinet, Gigabit Ethernet, Infiniband
- and the VIA interface. We have tested MySQL Cluster so far only
- with SCI sockets. See <xref linkend="mysql-cluster-sci-sockets"/>
- for information on how to set up SCI sockets using ordinary TCP/IP
- for MySQL Cluster.
+ and the VIA interface. However, we have tested MySQL Cluster so
+ far only with SCI sockets. See
+ <xref linkend="mysql-cluster-sci-sockets"/>, for information on
+ how to set up SCI sockets using ordinary TCP/IP for MySQL Cluster.
</para>
</section>
Modified: trunk/refman-5.1/mysql-cluster-interconnects.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-interconnects.xml 2008-03-12 15:30:43 UTC (rev 10210)
+++ trunk/refman-5.1/mysql-cluster-interconnects.xml 2008-03-12 17:25:47 UTC (rev 10211)
Changed blocks: 2, Lines Added: 11, Lines Deleted: 112; 5903 bytes
@@ -713,110 +713,13 @@
</itemizedlist>
<para>
- To check the base performance of these access methods, we have
- developed a set of benchmarks. One such benchmark,
- <command>testReadPerf</command>, tests simple and batched primary
- and unique key accesses. This benchmark also measures the setup
- cost of range scans by issuing scans returning a single record.
- There is also a variant of this benchmark which uses a range scan
- to fetch a batch of records.
- </para>
-
- <para>
- In this way, we can determine the cost of both a single key access
- and a single record scan access, as well as measure the impact of
- the communication media used, on base access methods.
- </para>
-
- <remark role="todo">
- How current are these figures? [js]
- </remark>
-
- <para>
- In our tests, we ran the base benchmarks for both a normal
- transporter using TCP/IP sockets and a similar setup using SCI
- sockets. The figures reported in the following table are for small
- accesses of 20 records per access. The difference between serial
- and batched access decreases by a factor of 3 to 4 when using 2KB
- records instead. SCI Sockets were not tested with 2KB records.
- Tests were performed on a cluster with 2 data nodes running on 2
- dual-CPU machines equipped with AMD MP1900+ processors.
- </para>
-
- <informaltable>
- <tgroup cols="3">
- <colspec colwidth="33*"/>
- <colspec colwidth="34*"/>
- <colspec colwidth="33*"/>
- <tbody>
- <row>
- <entry><emphasis role="bold">Access Type</emphasis></entry>
- <entry><emphasis role="bold">TCP/IP Sockets</emphasis></entry>
- <entry><emphasis role="bold">SCI Socket</emphasis></entry>
- </row>
- <row>
- <entry>Serial pk access</entry>
- <entry>400 microseconds</entry>
- <entry>160 microseconds</entry>
- </row>
- <row>
- <entry>Batched pk access</entry>
- <entry>28 microseconds</entry>
- <entry>22 microseconds</entry>
- </row>
- <row>
- <entry>Serial uk access</entry>
- <entry>500 microseconds</entry>
- <entry>250 microseconds</entry>
- </row>
- <row>
- <entry>Batched uk access</entry>
- <entry>70 microseconds</entry>
- <entry>36 microseconds</entry>
- </row>
- <row>
- <entry>Indexed eq-bound</entry>
- <entry>1250 microseconds</entry>
- <entry>750 microseconds</entry>
- </row>
- <row>
- <entry>Index range</entry>
- <entry>24 microseconds</entry>
- <entry>12 microseconds</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>SCI, performance <foreignphrase>vs</foreignphrase> TCP/IP</secondary>
- </indexterm>
-
- <para>
- We also performed another set of tests to check the performance of
- SCI Sockets <foreignphrase>vis-à-vis</foreignphrase> that of the
- SCI transporter, and both of these as compared with the TCP/IP
- transporter. All these tests used primary key accesses either
- serially and multi-threaded, or multi-threaded and batched.
- </para>
-
- <para>
- The tests showed that SCI sockets were about 100% faster than
- TCP/IP. The SCI transporter was faster in most cases compared to
- SCI sockets. One notable case occurred with many threads in the
- test program, which showed that the SCI transporter did not
- perform very well when used for the <command>mysqld</command>
- process.
- </para>
-
- <para>
- Our overall conclusion was that, for most benchmarks, using SCI
- sockets improves performance by approximately 100% over TCP/IP,
- except in rare instances when communication performance is not an
- issue. This can occur when scan filters make up most of processing
- time or when very large batches of primary key accesses are
- achieved. In that case, the CPU processing in the
+ With benchmarks developed internally by MySQL for testing simple
+ and batched primary and unique key accesses, we have found that
+ using SCI sockets improves performance by approximately 100% over
+ TCP/IP, except in rare instances when communication performance is
+ not an issue. This can occur when scan filters make up most of
+ processing time or when very large batches of primary key accesses
+ are achieved. In that case, the CPU processing in the
<command>ndbd</command> processes becomes a fairly large part of
the overhead.
</para>
@@ -838,17 +741,13 @@
as well.)
</para>
- <remark role="todo">
- Provide links to these? (Not high priority item.) [js]
- </remark>
-
<para>
There are several other optimized socket implementations for
computer clusters, including Myrinet, Gigabit Ethernet, Infiniband
- and the VIA interface. We have tested MySQL Cluster so far only
- with SCI sockets. See <xref linkend="mysql-cluster-sci-sockets"/>
- for information on how to set up SCI sockets using ordinary TCP/IP
- for MySQL Cluster.
+ and the VIA interface. However, we have tested MySQL Cluster so
+ far only with SCI sockets. See
+ <xref linkend="mysql-cluster-sci-sockets"/>, for information on
+ how to set up SCI sockets using ordinary TCP/IP for MySQL Cluster.
</para>
</section>
Modified: trunk/refman-6.0/mysql-cluster-interconnects.xml
===================================================================
--- trunk/refman-6.0/mysql-cluster-interconnects.xml 2008-03-12 15:30:43 UTC (rev 10210)
+++ trunk/refman-6.0/mysql-cluster-interconnects.xml 2008-03-12 17:25:47 UTC (rev 10211)
Changed blocks: 2, Lines Added: 11, Lines Deleted: 112; 5903 bytes
@@ -712,110 +712,13 @@
</itemizedlist>
<para>
- To check the base performance of these access methods, we have
- developed a set of benchmarks. One such benchmark,
- <command>testReadPerf</command>, tests simple and batched primary
- and unique key accesses. This benchmark also measures the setup
- cost of range scans by issuing scans returning a single record.
- There is also a variant of this benchmark which uses a range scan
- to fetch a batch of records.
- </para>
-
- <para>
- In this way, we can determine the cost of both a single key access
- and a single record scan access, as well as measure the impact of
- the communication media used, on base access methods.
- </para>
-
- <remark role="todo">
- How current are these figures? [js]
- </remark>
-
- <para>
- In our tests, we ran the base benchmarks for both a normal
- transporter using TCP/IP sockets and a similar setup using SCI
- sockets. The figures reported in the following table are for small
- accesses of 20 records per access. The difference between serial
- and batched access decreases by a factor of 3 to 4 when using 2KB
- records instead. SCI Sockets were not tested with 2KB records.
- Tests were performed on a cluster with 2 data nodes running on 2
- dual-CPU machines equipped with AMD MP1900+ processors.
- </para>
-
- <informaltable>
- <tgroup cols="3">
- <colspec colwidth="33*"/>
- <colspec colwidth="34*"/>
- <colspec colwidth="33*"/>
- <tbody>
- <row>
- <entry><emphasis role="bold">Access Type</emphasis></entry>
- <entry><emphasis role="bold">TCP/IP Sockets</emphasis></entry>
- <entry><emphasis role="bold">SCI Socket</emphasis></entry>
- </row>
- <row>
- <entry>Serial pk access</entry>
- <entry>400 microseconds</entry>
- <entry>160 microseconds</entry>
- </row>
- <row>
- <entry>Batched pk access</entry>
- <entry>28 microseconds</entry>
- <entry>22 microseconds</entry>
- </row>
- <row>
- <entry>Serial uk access</entry>
- <entry>500 microseconds</entry>
- <entry>250 microseconds</entry>
- </row>
- <row>
- <entry>Batched uk access</entry>
- <entry>70 microseconds</entry>
- <entry>36 microseconds</entry>
- </row>
- <row>
- <entry>Indexed eq-bound</entry>
- <entry>1250 microseconds</entry>
- <entry>750 microseconds</entry>
- </row>
- <row>
- <entry>Index range</entry>
- <entry>24 microseconds</entry>
- <entry>12 microseconds</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>SCI, performance <foreignphrase>vs</foreignphrase> TCP/IP</secondary>
- </indexterm>
-
- <para>
- We also performed another set of tests to check the performance of
- SCI Sockets <foreignphrase>vis-à-vis</foreignphrase> that of the
- SCI transporter, and both of these as compared with the TCP/IP
- transporter. All these tests used primary key accesses either
- serially and multi-threaded, or multi-threaded and batched.
- </para>
-
- <para>
- The tests showed that SCI sockets were about 100% faster than
- TCP/IP. The SCI transporter was faster in most cases compared to
- SCI sockets. One notable case occurred with many threads in the
- test program, which showed that the SCI transporter did not
- perform very well when used for the <command>mysqld</command>
- process.
- </para>
-
- <para>
- Our overall conclusion was that, for most benchmarks, using SCI
- sockets improves performance by approximately 100% over TCP/IP,
- except in rare instances when communication performance is not an
- issue. This can occur when scan filters make up most of processing
- time or when very large batches of primary key accesses are
- achieved. In that case, the CPU processing in the
+ With benchmarks developed internally by MySQL for testing simple
+ and batched primary and unique key accesses, we have found that
+ using SCI sockets improves performance by approximately 100% over
+ TCP/IP, except in rare instances when communication performance is
+ not an issue. This can occur when scan filters make up most of
+ processing time or when very large batches of primary key accesses
+ are achieved. In that case, the CPU processing in the
<command>ndbd</command> processes becomes a fairly large part of
the overhead.
</para>
@@ -837,17 +740,13 @@
as well.)
</para>
- <remark role="todo">
- Provide links to these? (Not high priority item.) [js]
- </remark>
-
<para>
There are several other optimized socket implementations for
computer clusters, including Myrinet, Gigabit Ethernet, Infiniband
- and the VIA interface. We have tested MySQL Cluster so far only
- with SCI sockets. See <xref linkend="mysql-cluster-sci-sockets"/>
- for information on how to set up SCI sockets using ordinary TCP/IP
- for MySQL Cluster.
+ and the VIA interface. However, we have tested MySQL Cluster so
+ far only with SCI sockets. See
+ <xref linkend="mysql-cluster-sci-sockets"/>, for information on
+ how to set up SCI sockets using ordinary TCP/IP for MySQL Cluster.
</para>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r10211 - in trunk: refman-4.1 refman-5.0 refman-5.1 refman-6.0 | jon | 12 Mar |
