From: jon Date: March 12 2008 5:25pm Subject: svn commit - mysqldoc@docsrva: r10211 - in trunk: refman-4.1 refman-5.0 refman-5.1 refman-6.0 List-Archive: http://lists.mysql.com/commits/43869 Message-Id: <200803121725.m2CHPlVg032121@docsrva.mysql.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 @@ - To check the base performance of these access methods, we have - developed a set of benchmarks. One such benchmark, - testReadPerf, 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. - - - - 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. - - - - How current are these figures? [js] - - - - 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. - - - - - - - - - - Access Type - TCP/IP Sockets - SCI Socket - - - Serial pk access - 400 microseconds - 160 microseconds - - - Batched pk access - 28 microseconds - 22 microseconds - - - Serial uk access - 500 microseconds - 250 microseconds - - - Batched uk access - 70 microseconds - 36 microseconds - - - Indexed eq-bound - 1250 microseconds - 750 microseconds - - - Index range - 24 microseconds - 12 microseconds - - - - - - - MySQL Cluster - SCI, performance <foreignphrase>vs</foreignphrase> TCP/IP - - - - We also performed another set of tests to check the performance of - SCI Sockets vis-à-vis 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. - - - - 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 mysqld - process. - - - - 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 ndbd processes becomes a fairly large part of the overhead. @@ -823,17 +726,13 @@ as well.) - - Provide links to these? (Not high priority item.) [js] - - 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 - 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 + , for information on + how to set up SCI sockets using ordinary TCP/IP for MySQL Cluster. 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 @@ - To check the base performance of these access methods, we have - developed a set of benchmarks. One such benchmark, - testReadPerf, 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. - - - - 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. - - - - How current are these figures? [js] - - - - 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. - - - - - - - - - - Access Type - TCP/IP Sockets - SCI Socket - - - Serial pk access - 400 microseconds - 160 microseconds - - - Batched pk access - 28 microseconds - 22 microseconds - - - Serial uk access - 500 microseconds - 250 microseconds - - - Batched uk access - 70 microseconds - 36 microseconds - - - Indexed eq-bound - 1250 microseconds - 750 microseconds - - - Index range - 24 microseconds - 12 microseconds - - - - - - - MySQL Cluster - SCI, performance <foreignphrase>vs</foreignphrase> TCP/IP - - - - We also performed another set of tests to check the performance of - SCI Sockets vis-à-vis 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. - - - - 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 mysqld - process. - - - - 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 ndbd processes becomes a fairly large part of the overhead. @@ -837,17 +740,13 @@ as well.) - - Provide links to these? (Not high priority item.) [js] - - 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 - 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 + , for information on + how to set up SCI sockets using ordinary TCP/IP for MySQL Cluster. 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 @@ - To check the base performance of these access methods, we have - developed a set of benchmarks. One such benchmark, - testReadPerf, 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. - - - - 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. - - - - How current are these figures? [js] - - - - 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. - - - - - - - - - - Access Type - TCP/IP Sockets - SCI Socket - - - Serial pk access - 400 microseconds - 160 microseconds - - - Batched pk access - 28 microseconds - 22 microseconds - - - Serial uk access - 500 microseconds - 250 microseconds - - - Batched uk access - 70 microseconds - 36 microseconds - - - Indexed eq-bound - 1250 microseconds - 750 microseconds - - - Index range - 24 microseconds - 12 microseconds - - - - - - - MySQL Cluster - SCI, performance <foreignphrase>vs</foreignphrase> TCP/IP - - - - We also performed another set of tests to check the performance of - SCI Sockets vis-à-vis 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. - - - - 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 mysqld - process. - - - - 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 ndbd processes becomes a fairly large part of the overhead. @@ -838,17 +741,13 @@ as well.) - - Provide links to these? (Not high priority item.) [js] - - 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 - 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 + , for information on + how to set up SCI sockets using ordinary TCP/IP for MySQL Cluster. 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 @@ - To check the base performance of these access methods, we have - developed a set of benchmarks. One such benchmark, - testReadPerf, 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. - - - - 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. - - - - How current are these figures? [js] - - - - 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. - - - - - - - - - - Access Type - TCP/IP Sockets - SCI Socket - - - Serial pk access - 400 microseconds - 160 microseconds - - - Batched pk access - 28 microseconds - 22 microseconds - - - Serial uk access - 500 microseconds - 250 microseconds - - - Batched uk access - 70 microseconds - 36 microseconds - - - Indexed eq-bound - 1250 microseconds - 750 microseconds - - - Index range - 24 microseconds - 12 microseconds - - - - - - - MySQL Cluster - SCI, performance <foreignphrase>vs</foreignphrase> TCP/IP - - - - We also performed another set of tests to check the performance of - SCI Sockets vis-à-vis 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. - - - - 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 mysqld - process. - - - - 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 ndbd processes becomes a fairly large part of the overhead. @@ -837,17 +740,13 @@ as well.) - - Provide links to these? (Not high priority item.) [js] - - 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 - 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 + , for information on + how to set up SCI sockets using ordinary TCP/IP for MySQL Cluster.