A Look at Mysql 5.0 Performance Benchmarks

A Look at MySQL 5.0 Performance Benchmarks

® A MySQL Technical White Paper

May 2006

1 Introduction...... 4

2 Why is MySQL So Fast?...... 4 2.1 The MySQL Pluggable Storage Engine Architecture ...... 4 2.2 Features that Contribute to Fast MySQL Performance...... 6

3 Factors to Consider in Evaluating Database Performance...... 6

4 Several MySQL 5.0 Benchmarks ...... 8 4.1 TM1 Benchmark ...... 8 4.2 DBT2 Benchmark ...... 9 4.3 SUN Sysbench OLTP Benchmark ...... 10 4.4 c’t Magazine Database Performance Contest...... 12 4.5 Scaleable Insert Benchmark...... 12

5 Previous MySQL Benchmarks...... 13 5.1 eWeek Benchmark ...... 13 5.2 SPECjAppServer Benchmarks ...... 15

6 Conclusion ...... 16

7 Appendix A...... 16 7.1 Data Model ...... 16 7.2 Queries ...... 17 7.3 Workload...... 19 7.4 MySQL/InnoDB Configuration Parameters ...... 19

8 Appendix B...... 19 8.1 Hardware Configuration...... 20 8.2 MySQL/InnoDB Configuration...... 20

9 Appendix C...... 20 9.1 InnoDB Configuration Parameters ...... 21

10 Appendix D...... 21 10.1 Data Model ...... 21 10.2 Hardware Configuration...... 22

There is little doubt that two of the top requirements for any serious database management system are availability and performance. Not coincidentally, two of the three MySQL AB software priorities are reliability and performance (with the third being ease-of-use). MySQL makes it a mission to produce high-performance database software that more than meets the needs of today’s most demanding enterprise-class applications. The reputation that MySQL has earned as a fast- performing database is one that has come from both independent performance tests as well as daily serving as the backend database for high-volume applications at large customer installations.

MySQL continues its tradition of being a high-performance RDBMS with version 5.0, which was released in October, 2005. The adoption rate of version 5.0 has been extremely high, with polls showing that many have already moved to version 5.0 for production systems. One of the reasons cited for making the move was to take advantage of a number of the performance enhancements and new features made available in version 5.0.

This paper takes a look at how MySQL provides the exceptional performance that it is known for and showcases a number of internal and external benchmarks that provide proof that MySQL continues to be one of the fastest databases on the market today.

2 Why is MySQL So Fast?

As has already been mentioned, one of MySQL’s hallmarks is exceptionally fast performance. MySQL’s speed can be seen across all types of database operations – simple and complex queries, write-intensive operations, etc. – as well as in various different platform deployments and high-traffic concurrent user situations. Why is MySQL so fast? There are a number of elements that contribute to the excellent performance found in MySQL, including the pluggable storage engine architecture and high-performance features found in server, many of which are unique only to MySQL.

2.1 The MySQL Pluggable Storage Engine Architecture

Many large enterprises are choosing MySQL because it offers a new and different paradigm of database management. One key differentiator between MySQL and other database platforms – whether they are proprietary or open source – is the pluggable storage engine architecture of MySQL. What exactly is the MySQL pluggable storage engine architecture and what benefits does it offer to today’s modern enterprises?

The MySQL pluggable storage engine architecture allows a database professional to select a specialized storage engine for a particular application need while being completely shielded from the need to manage any specific application coding requirements. Graphically depicted, the MySQL pluggable storage engine architecture looks like Figure 1:

Figure 1 - The MySQL Pluggable Storage Architecture

The pluggable storage engine architecture provides a standard set of management and support services that are common among all underlying storage engines. The storage engines themselves are the components of the database server that actually perform actions on the underlying data that is maintained at the physical server level.

This efficient and modular architecture provides large performance benefits for those wishing to specifically target a particular application need – such as data warehousing, transaction processing, high availability situations, etc. – while enjoying the advantage of utilizing a set of interfaces and services that are independent of any one storage engine.

From a technical perspective some of the key differentiations in storage engines include:

• Concurrency – some applications have more granular lock requirements (such as row-level locks) than others. Choosing the right locking strategy can reduce overhead and therefore help with overall performance. This area also includes support for capabilities like multi- version concurrency control or “snapshot” read. • Transaction Support – not every application needs transactions, and for those that don’t, the overhead of such support is avoided. But for those that do, there are very well defined requirements in a number of MySQL’s storage engines like ACID compliance and more. • Physical Storage – this involves everything from the overall page size for tables and indexes as well as the format used for storing data to physical disk. Different storage strategies definitely have an impact on the overall performance of both read and write operations. • Index Support – different application scenarios tend to benefit from different index strategies, and so each storage engine generally has its own indexing methods, although some indexing mechanisms (like B-tree indexes) are common to nearly all engines. • Memory Caches – MySQL offers a couple of storage engines whose data only resides in RAM, which results in very fast performance. Others use different variations of memory caches for transactions, transaction logs, tables, and indexes.

Copyright © 2006, MySQL AB Page 5 of 22 • Performance Aids – includes things like multiple I/O threads for parallel operations, thread concurrency, database checkpointing, bulk insert handling, and more. .

Each set of the pluggable storage engine infrastructure components are designed to offer a selective set of benefits for a particular application. Conversely, avoiding a set of component features helps steer clear of unnecessary overhead. So it stands to reason that understanding a particular application’s set of requirements and selecting the proper MySQL storage engine can have a dramatic impact on overall system efficiency and performance. And a DBA can put multiple storage engines in play for the same application, which equates to the DBA having an extremely flexible and high-performance framework at their disposal for satisfying the exact requirements of an application.

2.2 Features that Contribute to Fast MySQL Performance

Besides the pluggable storage engine architecture advantage, MySQL offers a number of core features that contribute to its reputation of being an extremely fast database management system. Some of these features include:

• Query Cache – besides the standard SQL/data/index/log caches offered by other database vendors, MySQL provides a unique query cache that has the potential to substantially increase overall response time, especially if identical queries are repetitively issued. If enabled, MySQL retains not only the SQL query that was issued, but also the query’s result set. This differs from just keeping the query and the raw data in memory, as MySQL does not have to re-produce the result set each time. This results in a dramatic decrease in logical and physical I/O and a near instantaneous response time rate. • Robust Indexing Choices – MySQL provides standard B-tree indexing as well as support for Clustered, Geospatial, Hash, Sparse, and Full-Text indexes. Key to any fast database system is good index design, and MySQL does not disappoint with respect to providing numerous choices for indexing a table. • Fast Data Load Options – MySQL serves as the backend for receiving huge volumes of information for many customer installations. Few database systems offer the type of write performance as MySQL. This can be contributed to things like MySQL’s unique multi-insert statement capability, the Archive storage engine (which is the fastest engine in MySQL when it comes to data load performance), a parallel load utility, and other miscellaneous features. • High-Speed Connection Pool – applications that serve high volumes of concurrent users will benefit from MySQL’s server-side thread pools and connection thread caching. These features allow for the fast establishment of incoming user connections so that a user’s work can immediately be carried out. • Main Memory Data Access – as has already been mentioned, MySQL offers a number of different storage engines, two of which offer continuous main memory access to data. While data caches exist for the majority of core MySQL storage engines, the Memory storage engine and the NDB Cluster storage engine offer the ability to guarantee a table’s information is always in RAM for the fastest possible access. • Easy Scale-Out Implementation – many MySQL customers create scale-out architectures that partition and load balance workloads across many commodity servers. MySQL’s incredibly easy-to-use and reliable replication mechanisms are used to scale performance so that no workload becomes too great to handle.

3 Factors to Consider in Evaluating Database Performance

There are many different ways to test and evaluate a database system’s performance. The most common technique for measuring performance is to take a black box approach that measures the Transactions Per Second (TPS) an application is able to execute against a database, which does not

Copyright © 2006, MySQL AB Page 6 of 22 necessarily refer to an ACID-compliant transaction. The value of a benchmark that measures TPS is directly tied to the type of transactions being performed. A test that measures the number of simple read queries that can execute will yield different results than a test that measures the number of multi- table inserts. So, the absolute value of a TPS metric is not as useful as a TPS metric that is compared against many tests that vary a small number of variables. Finally, it’s important to note that it’s not useful to measure the TPS value of one type of test against a TPS value of a completely different test. For example, the TPS values from SPEC tests are not comparable with those of TPC tests.

Variables that can be altered and affect performance include, but are not limited to:

Variable Impact Hardware The speed of the CPU, the CPU architecture, number of CPUs or CPU cores, bus interconnect speed, memory access speed, raw I/O capability, disk hardware and configuration including seek speed, network hardware and interface speed, are all items that a database depends upon and can impact the performance of a database. Operating System Variability in the performance of native API file, threading, locking, and memory can impact the performance of a common benchmark run on different operating systems. Number of Client The number of clients concurrently attempting to Connections connect to a database can measure its ability to handle increasing amounts of burden. Level of DB Concurrency The number of threads inside the database (controlled in MySQL by the total number of connections since there is a direct correlation) can impact the parallelism of the system. Too few parallel threads means that the system will under perform and too many parallel threads may cause the system to spend too much time managing thread overhead instead of executing transactions. Data Schema The structure of the database schema used in the test. The type of test, or workload, that is defined would vary between a test that uses a database with a single table versus a test on a database with 1000s of tables with complex foreign key relationships. There is a difference between the “workload” of a test which corresponds to the actions applied to a database versus the “logical” schema (structure of the data). In most pre-defined independent tests, the logical schema is defined along with a set of transactions to execute against that schema to define the workload pattern. Volume of Data A test on a database with a large volume of data will be a stronger measure of the effectiveness of the index implementation than a test on a database with a low amount of data. Type of Application Read-only, read-mostly, and read-write applications are a good reflection of data warehousing, eCommerce, and financial applications, respectively. Varying tests on the type of application will provide a good measure of how a system handles read operations versus data modification operations. TPS is a good measure used in OLTP workloads and you will typically see “length of

Copyright © 2006, MySQL AB Page 7 of 22 time” measurements on workloads that represent a read-mostly / batch bulk update pattern (even though TPS and length of time measurements can be calculated form one another). Additionally, the type of application chosen will have a direct impact on the use (or not) of ACID-transactions in a test, which can have a huge impact on TPS. Data Access Pattern Since most applications access less than 5% of the data in a database more than 90% of the time, a test that follows this standard distribution will measure the effectiveness of a system’s caching abilities. A uniform test that accesses different data equally is a better measure of the database’s raw performance when most operations are executed against a raw disk partition. Also the data access pattern is an important aspect in how the workload will be defined (focus on transactional throughput or speed of a batch update?). Database Configuration MySQL allows a DBA or developer to modify parameters including the maximum number of client connections, the size of the query cache, the execution style of different logs, index memory cache size, the network protocol used for client-server communications, and dozens of others.

Of course, with nearly an infinite number of variables that can alter the results of a benchmark, it’s important to use a benchmark that mirrors the intended application workload.

4 Several MySQL 5.0 Benchmarks

What follows are several benchmarks that highlight MySQL 5.0, some of which compare version 5.0 with an earlier release (version 4.1).

4.1 TM1 Benchmark

The TM1 benchmark simulates a small Home Location Register (HLR) telecommunications database used by a mobile carrier. The HLR is an application mobile network operators use to store all relevant information about valid subscribers, including the mobile phone number, the services to which they have subscribed, access privileges, and the current location of the subscriber's handset.

The following TM1 benchmark was run against MySQL 4.1 and 5.0, on an Intel P4, 2.8 GHz, 1G RAM machine using the InnoDB storage engine (both 5.0 and 4.1 with the same settings), 10 clients and 500K subscribers, using a connection through ODBC. The final end result was:

Maximum Qualified Throughput (MQth) MySQL 4.1 416.5 MySQL 5.0 554.6 Improvement in 5 vs. 4 33%

Figure 2 - TM1 Benchmark Results

This above graph shows throughput of MySQL (red = MySQL 4.1, green = MySQL 5.0). The X-axis is the entire test time (about 2hours, excluding time for "warm-up"), while the Y-axis is number of completed transaction in each second of the test.

Appendix A of this paper contains the data model, queries, and workload percentages used by the TM1 benchmark.

4.2 DBT2 Benchmark

The DBT2 benchmark is an open source performance test, which simulates a transaction processing environment. The following MySQL DBT2 results were derived from a cooperative effort between MySQL AB and AMD. For a complete listing of the hardware and MySQL configurations, please see Appendix B in this paper.

In addition to running the standard DBT2 benchmark, a test was performed to see if any performance increases could be obtained through the use of MySQL 5.0 stored procedures, which were not available in previous versions of the database. The test proved that stored procedures indeed provide a performance boost over the use of straight SQL.

The final results were:

Copyright © 2006, MySQL AB Page 9 of 22 4.1 (Txns per 5.0-sp (Txns Increase of 5.0 vs. Clients minute) per minute) 4.1 1 10871.74 13105.50 20.55% 2 18589.36 22016.15 18.43% 4 28806.35 32071.93 11.34% 8 28494.50 29864.95 4.81% 15 27061.83 27737.06 2.50% 20 26411.93 27279.27 3.28% 30 25791.74 26254.50 1.79% 50 25171.19 25405.50 0.93% 75 24723.30 24874.86 0.61% 100 24610.64 24185.69 -1.73%

DBT2

35000.00

30000.00

25000.00

M 20000.00 4.1 15000.00 5.0-sp NOTP 10000.00

5000.00

0.00 1 2 4 8 15 20 30 50 75 100 clients

Figure 3 - DBT2 Benchmark Results

4.3 SUN Sysbench OLTP Benchmark

SUN conducted several MySQL 5.0 benchmarks using the sysbench utility, which is a modular, cross- platform and multi-threaded benchmark tool for evaluating the performance of a system that is running a database under intensive load. The tests were conducted on a 4-CPU dual-core (8 total cores) Opteron Sun Fire V40z server, running Solaris 10.

The read/write sysbench test produced the following results:

User Transactions Load Per Second 1 422.09 2 755.14 4 1253.79

Sysbench Read/Write

2000 1500

S 1000 TP 500 0 1 2 4 8 16 32 64 128 256 512 1024 Clients

Figure 4 - SUN Sysbench Read/Write Benchmark

The read-only sysbench test produced the following results:

User Transactions Load Per Second 1 597.56 2 1105.57 4 1884.62 8 2814.54 16 2900.22 32 2831.01 64 2595.95 128 1954.72 256 1289.04 512 1057.18 1024 729.75

4000 3000

S 2000 TP 1000 0 1 2 4 8 16 32 64 128 256 512 1024 Clients

Figure 5 - SUN Sysbench Read-Only Benchmark

4.4 c’t Magazine Database Performance Contest

In 2006, the German IT magazine c’t ran a database performance contest where applicants were asked to reproduce the Dell DVD online store application using whatever platform, database, and programming language combination they believed would perform the best. The clear winner was the submission made by the MySQL performance benchmark team, which used MySQL 5.0 for the database backend.

The following results were observed:

Applicant Operating Database Language Operations System per Minute MySQL Benchmark Team Linux MySQL 5.0 PHP 5 3664 Alexander Burger Linux Pico Lisp 2.2.1 Pico Lisp 2.2.1 2600 MonetDB-Entwicklerteam Linux MonetDB 4.9 Java 1833 Jan Monnich Windows MySQL 5.0 Java 1798 USU Valuecoders Windows MySQL 4.1 Java 1564 Martin Winandy Windows MySQL 4.1 PHP 5 1542 IBM Linux DB2 Express 8.2 Java 1537 Frank Berger Linux Oracle10g Express Java 1412 Niklas Mehner Linux SiebenGeisslein Java 600 Exedio Linux MySQL 5.0 Java 587 FH Ulm Windows MySQL 5.0 PHP 5 444 Gerhard Kalab Windows MySQL 5.0 Python 2.4 137 bluegap Linux PostgresSQL 8.1 PHP 5 120

4.5 Scaleable Insert Benchmark

The following benchmark compares different MySQL 5.0 storage engines for insert-intensive operations. The engines tested include the MyISAM, InnoDB, and Archive storage engines. The test was run and information gathered using the Quest Benchmark Factory testing tool. Appendix D of this paper contains the data model, and hardware/MySQL configurations used for the test.

Copyright © 2006, MySQL AB Page 12 of 22 MyISAM InnoDB Archive User Inserts Per Inserts Per Inserts Per Load Second Second Second 1 3,203.00 2,670.00 3,576.00 4 9,123.00 5,280.00 11,038.00 8 9,361.00 5,044.00 13,202.00 16 8,957.00 4,424.00 13,066.00 32 8,470.00 3,934.00 12,921.00 64 8,382.00 3,541.00 12,571.00 128 8,186.00 3,568.00 9,431.00

14,000.00

12,000.00

c 10,000.00 Se

r 8,000.00 MyISAM 5.0.15

Pe InnoDB 5.0.15 s

t 6,000.00 r Archive 5.0.13 e s

n 4,000.00 I 2,000.00

0.00 1 4 8 16 32 64 128 User Load

Figure 6 - Insert Benchmark Test Results

As can be seen in the above benchmark, the Archive storage engine of MySQL currently offers the fastest throughput in terms of insert operations.

5 Previous MySQL Benchmarks

This section contains a number of independent benchmarks made against versions of MySQL that did not contain a number of the new optimizer improvements or stored procedures found in MySQL 5.0.

5.1 eWeek Benchmark

The eWeek Database Benchmark is an eCommerce application that has a Web interface that combines read and write queries. This test measures the performance of an overall system in terms of Web Pages per Second, which is equivalent to TPS since each Web page invokes a single transaction. Their findings show that MySQL has the best overall performance and that MySQL scalability matches Oracle. Additionally, their tests showed that MySQL excelled in stability, ease of tuning, and connectivity options. Finally, they also found that MySQL had the highest throughput, even exceeding the numbers generated by Oracle.

Figure 5 eWeek Database Benchmark – Throughput (higher is better)

Figure 6 - eWeek Database Benchmark – Response Times (lower is better)

Comments from eWeek reviewer Timothy Dyck include the following:

• "Of the five databases we tested, only Oracle9i and MySQL were able to run our Nile application as originally written for 8 hours without problems." • "The Oracle and MySQL drivers had the best combination of a complete JDBC feature set and stability."

5.2 SPECjAppServer Benchmarks

At the end of 2004, MySQL teamed with BEA and Sun to post new results for the SPECjAppServer2002 benchmark. A MySQL database running with BEA’s WebLogic Server on Sun Microsystems’ Sun Fire hardware set world records for speed and price/performance as published by the Standard Performance Evaluation Corp. (SPEC). SPECjAppServer2002 is an industry benchmark, administered by SPEC used to measure the performance of J2EE application server platforms connecting with a database. It is designed to model a real-world manufacturing, supply-chain management and order/inventory application.

The competitive benchmark results listed below were performed on standard x86 processors including AMD’s Opteron, Intel’s Xeon and Itanium. They reflect results posted as of September 2, 2004. SPECjAppServer2002 measures based upon TOPS (Total Operations per Second) and also on US$/TOPS, which is the total cost of the entire system (hardware + licensing + support fees) divided by TOPS.

Price/Performance value (Lower numbers demonstrate better price/performance) Database App Server Database Hardware App Server Hardware US$/TOPS MySQL BEA WebLogic Sun Fire V40z Sun Fire V20z $82.74 SQL BEA WebLogic Unisys ES7000 Aries 410 Unisys ES3020L Server $139.84 Server Oracle Oracle HP ProLiant DL580 G2 HP ProLiant ML370 G3 $150.68 SQL BEA WebLogic Unisys ES7000 Aries 420 Unisys ES3020L Server $157.66 Server Oracle Oracle HP ProLiant DL580 G2 HP ProLiant ML370 G3 $168.62 SQL BEA WebLogic HP ProLiant DL580 G2 HP ProLiant DL360 G3 $200.34 Server IBM IBM eServer pSeries IBM eServer xSeries IBM DB2 $330.07 Websphere p650 x335 Figure 7 - SPECAppServer Price/Performance Results for MySQL

Performance of entries with databases running on 4-processor hardware (Higher numbers demonstrate faster performance) Database App Server Database Hardware App Server Hardware TOPS MySQL BEA WebLogic Sun Fire V40z Sun Fire V20z 1363.88 Oracle Oracle HP ProLiant DL580 G2 HP ProLiant ML370 G3 1165.06 SQL Server BEA WebLogic HP ProLiant DL580 G2 HP ProLiant DL360 G3 1037.02 Oracle Oracle HP ProLiant DL580 G2 HP ProLiant ML370 G3 863.40 Figure 8 - SPECAppServer Performance Results for MySQL

As the two top requirements for any serious database management system are availability and performance, MySQL AB takes great care to ensure that each are given top priority in every release of the MySQL server. Version 5.0 of MySQL continues the strong tradition of keeping overhead down and speed up for systems that need to squeeze every last drop of performance from their applications.

Those wishing to learn more about the MySQL database server can visit www.mysql.com/products/database for more details. In addition, for those interested in learning how to best tune and configure MySQL for optimum performance should investigate MySQL’s consulting packages that specialize in tuning and optimization. More information on these packages can be found at: http://www.mysql.com/consulting/packaged/performance.html.

7 Appendix A

This appendix contains the data model, queries, and workload percentages used by the TM1 benchmark.

7.1 Data Model

The following tables were used in the TM1 benchmark:

CREATE TABLE Subscriber ( s_id INTEGER NOT NULL PRIMARY KEY, sub_nbr VARCHAR(15) NOT NULL UNIQUE, bit_1 TINYINT, bit_2 TINYINT, bit_3 TINYINT, bit_4 TINYINT, bit_5 TINYINT, bit_6 TINYINT, bit_7 TINYINT, bit_8 TINYINT, bit_9 TINYINT, bit_10 TINYINT, hex_1 TINYINT, hex_2 TINYINT, hex_3 TINYINT, hex_4 TINYINT, hex_5 TINYINT, hex_6 TINYINT, hex_7 TINYINT, hex_8 TINYINT, hex_9 TINYINT, hex_10 TINYINT, byte2_1 SMALLINT, byte2_2 SMALLINT, byte2_3 SMALLINT, byte2_4 SMALLINT, byte2_5 SMALLINT, byte2_6 SMALLINT, byte2_7 SMALLINT, byte2_8 SMALLINT, byte2_9 SMALLINT, byte2_10 SMALLINT,

Copyright © 2006, MySQL AB Page 16 of 22 msc_location INTEGER, vlr_location INTEGER); CREATE TABLE Access_Info ( s_id INTEGER NOT NULL, ai_type TINYINT NOT NULL, data1 SMALLINT, data2 SMALLINT, data3 CHAR(3), data4 CHAR(5), PRIMARY KEY(s_id, ai_type), FOREIGN KEY (s_id) REFERENCES Subscriber (s_id));

CREATE TABLE Special_Facility ( s_id INTEGER NOT NULL, sf_type TINYINT NOT NULL, is_active TINYINT NOT NULL, error_cntrl SMALLINT, data_a SMALLINT, data_b CHAR(5), PRIMARY KEY (s_id, sf_type), FOREIGN KEY (s_id) REFERENCES Subscriber (s_id));

CREATE TABLE Call_Forwarding ( s_id INTEGER NOT NULL, sf_type TINYINT NOT NULL, start_time TINYINT NOT NULL, end_time TINYINT, numberx VARCHAR(15), PRIMARY KEY (s_id, sf_type, start_time), FOREIGN KEY (s_id, sf_type) REFERENCES Special_Facility(s_id, sf_type));

7.2 Queries

The following queries were issued during the TM1 benchmark:

GET_SUBSCRIBER_DATA

SELECT s_id, sub_nbr, bit_1, bit_2, bit_3, bit_4, bit_5, bit_6, bit_7, bit_8, bit_9, bit_10, hex_1, hex_2, hex_3, hex_4, hex_5, hex_6, hex_7, hex_8, hex_9, hex_10,byte2_1, byte2_2, byte2_3, byte2_4, byte2_5, byte2_6, byte2_7,byte2_8, byte2_9, byte2_10, msc_location, vlr_location FROM subscriber WHERE s_id = ;

GET_NEW_DESTINATION

SELECT cf.numberx FROM special_facility AS sf, call_forwarding AS cf WHERE (sf.s_id = AND sf.sf_type = AND sf.is_active = 1) AND (cf.s_id = sf.s_id AND

GET_ACCESS_DATA

SELECT data1, data2, data3, data4 FROM access_info WHERE s_id = AND ai_type = ;

UPDATE_SUBSCRIBER_DATA

UPDATE subscriber SET bit_1 = WHERE s_id = ;

UPDATE special_facility SET data_a = WHERE s_id = AND sf_type = ;

UPDATE_LOCATION

UPDATE subscriber SET vlr_location = WHERE sub_nbr = ;

DELETE_CALL_FORWARDING

SELECT FROM subscriber WHERE sub_nbr = ;

DELETE FROM call_forwarding WHERE s_id = AND sf_type = AND start_time = ;

INSERT_CALL_FORWARDING

SELECT

SELECT FROM special_facility WHERE s_id = ;

INSERT INTO call_forwarding VALUES (, , , , );

7.3 Workload

The workload used for the TM1 benchmark was as follows:

Query Workload Percentage GET_SUBSCRIBER_DATA 35% GET_NEW_DESTINATION 10% GET_ACCESS_DATA 35% UPDATE_SUBSCRIBER_DATA 2% UPDATE_LOCATION 14% INSERT_CALL_FORWARDING 2% DELETE_CALL_FORWARDING 2%

7.4 MySQL/InnoDB Configuration Parameters

The following parameters were used during the benchmark test for the InnoDB storage engine:

innodb_additional_mem_pool_size = 16M innodb_buffer_pool_size = 200M innodb_data_file_path = ibdata1:10M:autoextend innodb_file_io_threads = 4 innodb_thread_concurrency = 16 innodb_flush_log_at_trx_commit = 0 innodb_log_buffer_size = 8M innodb_log_file_size = 100M innodb_lock_wait_timeout = 120

8 Appendix B

This appendix contains the hardware and MySQL configurations used for the DBT2 benchmark profiled in this paper.

8.1 Hardware Configuration

• 4 Processor Single Core AMD Opteron™ Processor 850, cache size 1024 KB, 2389MHz • 3GB RAM • Red Hat Enterprise Linux AS Release 4 (Nahant Update 2)

8.2 MySQL/InnoDB Configuration

The following parameters were used during the DBT2 benchmark test for MySQL and the InnoDB storage engine:

--port=3306 --socket=/tmp/mysql.sock --user=root $LOGERR --datadir=$FSPATH --basedir=$BASEPATH --max_connections=3000 --max_connect_errors=10 --table_cache=2048 --max_allowed_packet=1M --binlog_cache_size=1M --max_heap_table_size=64M --sort_buffer_size=64K --join_buffer_size=1M --thread_cache=16 --thread_concurrency=16 --thread_stack=196K --query_cache_size=0 --ft_min_word_len=4 --default_table_type=MYISAM --transaction_isolation=REPEATABLE-READ --tmp_table_size=64M --skip-locking --server-id=1 --innodb_status_file=0 --innodb_data_home_dir=$FSPATH --innodb_data_file_path=ibdata1:100M:autoextend --innodb_log_group_home_dir=$FSPATH --innodb_buffer_pool_size=1800M --innodb_additional_mem_pool_size=20M --innodb_log_file_size=900M --innodb_log_files_in_group=2 --innodb_log_buffer_size=8M --innodb_flush_log_at_trx_commit=2 --innodb_lock_wait_timeout=300 --innodb_locks_unsafe_for_binlog=1 --innodb_thread_concurrency=1000

9 Appendix C

This appendix contains the configuration used by SUN corporation during the testing of MySQL 5 on Solaris 10.

9.1 InnoDB Configuration Parameters

# The MySQL server [mysqld] port = 3306 socket = /tmp/mysql.sock skip-locking max-connections = 3500 set-variable = key_buffer=1600M #user = mysql transaction_isolation = REPEATABLE-READ innodb_data_file_path = ibdata1:100M:autoextend innodb_buffer_pool_size = 1G innodb_additional_mem_pool_size = 20M innodb_log_file_size = 1900M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 2 innodb_lock_wait_timeout = 300 innodb_locks_unsafe_for_binlog = 1 innodb_max_dirty_pages_pct = 90 innodb_thread_concurrency = 10 #innodb_commit_concurrency = 20 [isamchk] set-variable = key_buffer=12M

10 Appendix D

This appendix contains the data model and hardware/MySQL configuration used for the scaleable insert benchmark.

10.1 Data Model

The following table was used for the scaleable insert benchmark:

mysql> desc SH_InsertTable; +------+------+------+-----+------+------+ | Field | Type | Null | Key | Default | Extra | +------+------+------+-----+------+------+ | Project_Number | int(11) | NO | | | | | Model | int(11) | NO | | | | | ProductID | int(11) | NO | | | | | Product_Name | char(32) | NO | | | | | Price | double | NO | | | | | Class | int(11) | NO | | | | | Evaluations | char(20) | NO | | | | | Description | char(50) | NO | | | | | EmployeeID | int(11) | NO | | | | | Type | int(11) | NO | | | | | VendorID | int(11) | NO | | | | +------+------+------+-----+------+------+

• Single Processor Intel Pentium 4 x86 Processor, 3.0GHz • 1GB RAM • Fedora Core 4

10.3 MySQL/InnoDB Configuration

The following parameters were used during the scaleable insert benchmark test for MySQL. Note that the connection from the Quest Benchmark Factory tool to the MySQL database was established through ODBC.

server-id=1 user mysql port 3306 default_storage_engine=myisam skip-locking key_buffer = 300M max_allowed_packet = 15M table_cache = 1024 sort_buffer_size = 10M read_buffer_size = 10M read_rnd_buffer_size = 10M myisam_sort_buffer_size = 64M thread_cache = 16 join_buffer_size=10M query_cache_size = 0M thread_concurrency = 16 innodb_data_file_path = ibdata1:200M:autoextend innodb_log_group_home_dir = /usr/local/mysql/data/ innodb_buffer_pool_size = 300M innodb_additional_mem_pool_size=20M innodb_log_file_size = 200M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 2 innodb_thread_concurrency=1000 max_connections=500 innodb_lock_wait_timeout=300