Currently Being Moderated

Performance Benchmark: Horizontal Scaling

One of the goals of SQLFire's design is to achieve a near-linear increase in throughput with an increasing number of concurrent clients and servers managing data. Below, we present a simple throughput benchmark demonstrating the raw throughput, latency, and level of scalability that can be achieved using commodity hardware. All tests used the SQLFire 1.0 release.

 

The test used 20 multicore commodity machines, 10 for storing the data with redundancy in memory and 10 to simulate a large number of concurrent clients. The hosts shared a 20 gigabit backplane. The specific details are available from VMware.

 

Test Description

The number of servers used for managing data is increased from 2 to 10, one per physical node. The number of physical nodes used to simulate the clients is also increased from 2 to 10. Each client node runs 4 Java VMs with N threads each (see the value of N for each test result below).

 

The client benchmark test was written in Java and used the peer JDBC driver.


The data is stored on the servers using a single table partitioned by primary key. The table contains an integer primary key plus 20 strings and 20 integers:

 

id int not null primary key

stringField1 varchar(20)

stringField2 varchar(20)

...

stringField20 varchar(20)

intField1 int

intfield2 int

...

intfield20 int


Each client thread executes operations using a prepared statement, as fast as it possibly can. Each operation uses a row chosen using a randomly generated primary key. The clients do some amount of warmup.

 

The test starts with two server nodes hosting data with two client nodes accessing the data and then progresses by increasing both the number of client nodes as well as the server nodes in proportion. The amount of data is also increased proportionately.


In the graphs of test results, the X-axis shows the increase in the number of servers (data hosts), the Y-axis on the right shows the number of concurrent client threads and the Y-axis on the left shows the aggregate performance observed across all the data hosts.

 

Partitioned Table Query Test

In this test, each client node runs 4 Java VMs with 24 threads each, for 96 client threads per node.  Each client thread does primary key queries using a prepared statement. Each query uses a randomly chosen primary key.


The results show that the aggregate throughput scales linearly when the client thread count scales in tandem with the available servers that host the data.  The number of servers (datahosts) is shown on the X axis.  The throughput is shown on the left-hand Y axis.  The client thread count is shown on the right-hand Y axis.

 

querypk.throughput.GIF

 

CPU utilization per client and per server is relatively stable as the number of nodes is scaled. Note the server CPU utilization remains low at roughly 40% indicating each server can handle a much higher concurrent load.

 

querypk.cpu.GIF

 

Over three quarters of all queries complete in under 1 ms, roughly 93% complete in under 2 ms, and 98% take under 5 ms.

 

 

querypk.response.GIF

 

Partitioned Table Update Test

In this test, each client node runs 4 Java VMs with 40 threads each, for 160 client threads per node.  Each client thread does updates using a prepared statement. The row used in each update is chosen using a randomly chosen primary key.  The update modifies one string column and two int columns:

 

               update large_object set lo.stringField3=?, lo.intField12=?, lo.intField18=? where lo.id=?

 

The results show that the aggregate throughput scales linearly when the client thread count scales in tandem with the available servers that host the data.  The number of servers (datahosts) is shown on the X axis.  The throughput is shown on the left-hand Y axis.  The client thread count is shown on the right-hand Y axis.

 

update.throughput.GIF

 

CPU utilization per client and per server is stable as the number of nodes is scaled.

update.cpu.GIF

Over 80% of updates complete in under 1 ms, and over 90% in under 2 ms.

 

update.response.GIF

 

Partitioned Table Mixed Read-Heavy Workload

In this test, each client node runs 4 Java VMs with 24 threads each, for 96 client threads per node.  Each client thread does a mix of primary key lookups and updates, as described above, using a prepared statement. 80% of the operations are reads and 20% are updates.

 

SQLFire continues to show horizontal scaling for both reads and writes, high throughput, low latencies, and consistent CPU activity.

 

mix20.throughput.queries.GIF

mix20.throughput.updates.GIF

mix20.cpu.GIF

 

mix20.response.GIF

Comments

Delete Document

Are you sure you want to delete this document?

More Like This

  • Retrieving data ...

Share This Page