VoltDB Blog » VoltDB Benchmarks

877,000 TPS with Erlang and VoltDB

Henning Diedrich — Fri, 05 Apr 2013 10:15:37 +0000

-Edited 5/2/13 by Henning Diedrich to correct configuration typos.

Running on a suitable EC2 configuration (see details below), with our new VoltDB Erlang driver we achieved 877,519 transactions per second.

I am Henning Diedrich [1], CEO of Eonblast Corporation[2] a games company. I would like to introduce the new Erlang VoltDB driver we created, a piece of software that allows two genre-defining technologies to work together: VoltDB [3] and Erlang [4].

The Driver

I first came to VoltDB on the hunt for a better database for heavy duty online-game servers. I experienced first hand [5] what a … Read more

686K TPS with Spring Framework Web App and VoltDB

Andrew Wilson — Tue, 26 Jun 2012 17:10:21 +0000

We’ve recently put up a series of blog posts describing the components of a Spring-MVC web application, including VoltDB as the database, that saves votes being called in for talent show contestants. Today I’ll talk about what happened when we benchmarked the Voter application on Amazon’s cloud platform. The short story – running on a suitable EC2 configuration (see details below), we achieved 686,000 TPS for a Spring-enabled application using VoltDB.

The Benchmark Application

I’ll start by summarizing the aforementioned blog posts, but you are welcome to read them:

Using the Spring @Schedule Annotation, Using the Spring Converter API … Read more

695k TPS with Node.js and VoltDB

Henning Diedrich — Tue, 17 Apr 2012 13:15:10 +0000

Hi, I’m Henning Diedrich, co-founder and CEO of Eonblast, Inc. I’m a guest contributor to VoltDB’s blog.

In February I was contacted by VoltDB about conducting a benchmarking project. The company had recently released an updated version of a Node.js client driver that had originally been authored by Jacob Wright, one of VoltDB’s community members. When I began looking into Node.js, it became clear that its architecture and scaling goals are quite well aligned with VoltDB’s, so I was intrigued by the idea of running a benchmark to see what the combined technologies could produce. Like all languages and libraries, … Read more

Is VOLTDB Really as Scalable as they Claim?

John Hugg — Tue, 01 Mar 2011 12:40:59 +0000

Baron Schwartz from Percona has published an analysis of VoltDB’s scaling performance on the MySQL Performance Blog. He has worked with our own Tim Callaghan to apply a mathematical model to the Scalability of VoltDB. The conclusion:

VoltDB is very scalable; it should scale to 120 partitions, 39 servers, and 1.6 million complex transactions per second at over 300 CPU cores…

and

…scaling a synchronously replicated, active-active master, fully ACID, always-consistent database to a 40-server cluster is impressive.

A few notes:

As Baron says, these benchmarks were based on our “Voter” example. We ship this example with our distribution … Read more

Overclocking Your Database Servers

Tim Callaghan — Mon, 11 Oct 2010 19:09:46 +0000

It seems like I’ve been programming forever (we’re talking TS-1000, TRS-80, and Commodore64). I’ve always been looking to improve the performance of my programs, especially database applications. Better performance can usually be attributed to one of the following:

New Hardware – [insert name of favorite hardware vendor] has just released new server technology that incorporates improved [RAM | CPU | Disk | RAID Controller]. At some point we’d purchase one of the new servers, install the OS and RDBMS software, restore a large database for benchmarking, and run scripts to test the performance. Performance always improved but it was never

High Availability and Cloudy Problems

John Hugg — Tue, 21 Sep 2010 12:45:46 +0000

VoltDB, like many distributed systems, achieves high availability through redundant processing nodes. VoltDB calls this K-Safety. Essentially, the distributed system can answer any request at at least K+1 servers, so it can tolerate at least K hardware failures. The operator specifies the value of K that they find is the best tradeoff between failure, robustness and cost. Other systems use the terms “replica set” to describe similar functionality.

Let’s talk about EC2-style clouds that provide you with a virtualized server at an hourly cost. Imagine you want to deploy a VoltDB instance of 3 nodes with K = 2, i.e. … Read more

Key Value Benchmark FAQ

John Hugg — Tue, 01 Jun 2010 13:00:20 +0000

This is a follow up to a previous post on Benchmarking VoltDB against Cassandra on Key-Value-like workloads.

What’s the point of this benchmark?

Point 1: Demonstrate SQL can be fast. Say what you want about our numbers and benchmark, but the language used to manipulate data was SQL and it clearly wasn’t bottlenecking VoltDB performance. We wanted to show the assumption that dropping SQL is a precondition for performance and scalability is false.

Point 2: VoltDB competes well on simple workloads like the key-value puts and gets, as well as complex workloads like our TPC-C like benchmark.

How … Read more

Key-Value Benchmarking

John Hugg — Tue, 25 May 2010 13:10:07 +0000

Edit on 6/2/10: Check out the follow up Benchmarking FAQ blog post with links to code.

The NoSQL movement was born of the need to scale data management with predicable cost. My subjective summary of the NoSQL credo: provide simpler core functionality, scale horizontally, leverage redundancy, expect and handle failures. These systems became known as NoSQL because SQL and schema was often given up for flexibility and simplicity. The name came about even though SQL was never the primary complaint; scalability was.

VoltDB was born to solve similar problems. Provide horizontal scalability at a cost per transaction that anyone … Read more