5 ms·

A few answers: Yes, the tests were run without an ORM. Although VoltDB is accessible via JDBC, best throughput is achieved with parameterized SQL embedded in

A few answers: Yes, the tests were run without an ORM. Although VoltDB is accessible via JDBC, best throughput is achieved with parameterized SQL embedded in Java stored procedures. That's how the Node.js benchmark app (Voter) was implemented. Node+Volt will be much faster than Node+Postgres or Node+MySQL for many OLTP-style workloads. So it's a great fit for apps like financial trading, digital advertising, online gaming and network monitoring - each of which requires super-high throughput writes (at single ms latencies) and fast, simple analytics. Node+Postgres or Node+MySQL would be a better fit for general purpose database workloads (e.g., with large-grained reporting). In-memory means that Volt stores all data in main memory. Durability is achieved through the use of a highly innovative command log, which logs all transaction invocations to persistent storage. You can tune this feature to log synchronously (100% guaranteed durability at reduced transaction latency) or asynchronously (slightly more "lossy", but less of a latency impact). VoltDB also recently released a full database replication feature that supports WAN replication for disaster recovery. I hope these responses are in some way helpful.

MichaelGG 14y ago
What were the latency statistics? How good of time sync were you able to get the EC2 instances?
- aweisberg 14y ago
  The intent of the test was to measure throughput. Since the API is asynchronous that means the client was submitting as much work as would fit in the queues at both client and server and any latency measurement would be a measurement of how long it takes to execute all queued requests in the pipeline and the pipeline is always kept full. I am able to get sub-millisecond offsets (as reported by ntpq -p) with m1.large instances, but I have never left them running long. I am not sure what Henning got when he ran. I pointed him to my blog post on the topic http://www.afewmoreamps.com/2011/07/configuring-ntp-for-voltdb.html http://www.afewmoreamps.com/2011/07/configuring-ntp-for-volt... On bare metal ntpdate reports offsets that are sub microsecond. I find that nodes sync up quickly if only one of them polls the public pool.
- brn5 14y ago
  Indeed, I didn't look at latency. For time sync, I got sub-millisec syncs after using Ariel's tip at http://www.afewmoreamps.com/2011/07/configuring-ntp-for-voltdb.html http://www.afewmoreamps.com/2011/07/configuring-ntp-for-volt... . Essentially, switching NTP off and manually running ntpdate -p 8 <server name> repeatedly can give you that. Just do it ten times in a row - I don't know why the normal operation of NTP doesn't achieve the same. This tight sync seemed to increase throughput by 2%. Because that was not so significant I did not further investigate the consequences of good or bad time syncing. The time sync that EC2 instances come with out of the box seemed to sometimes be good enough to run multiple VoltDB hosts without any additional syncing, sometimes not, and it seemed to vary quite a bit over time. So really you must deal with NTP in EC2, but of course you need NOT get the sync to sub-millisecond values.

MichaelGG 14y ago

What were the latency statistics? How good of time sync were you able to get the EC2 instances?

aweisberg 14y ago
The intent of the test was to measure throughput. Since the API is asynchronous that means the client was submitting as much work as would fit in the queues at both client and server and any latency measurement would be a measurement of how long it takes to execute all queued requests in the pipeline and the pipeline is always kept full. I am able to get sub-millisecond offsets (as reported by ntpq -p) with m1.large instances, but I have never left them running long. I am not sure what Henning got when he ran. I pointed him to my blog post on the topic http://www.afewmoreamps.com/2011/07/configuring-ntp-for-voltdb.html http://www.afewmoreamps.com/2011/07/configuring-ntp-for-volt... On bare metal ntpdate reports offsets that are sub microsecond. I find that nodes sync up quickly if only one of them polls the public pool.
brn5 14y ago
Indeed, I didn't look at latency. For time sync, I got sub-millisec syncs after using Ariel's tip at http://www.afewmoreamps.com/2011/07/configuring-ntp-for-voltdb.html http://www.afewmoreamps.com/2011/07/configuring-ntp-for-volt... . Essentially, switching NTP off and manually running ntpdate -p 8 <server name> repeatedly can give you that. Just do it ten times in a row - I don't know why the normal operation of NTP doesn't achieve the same. This tight sync seemed to increase throughput by 2%. Because that was not so significant I did not further investigate the consequences of good or bad time syncing. The time sync that EC2 instances come with out of the box seemed to sometimes be good enough to run multiple VoltDB hosts without any additional syncing, sometimes not, and it seemed to vary quite a bit over time. So really you must deal with NTP in EC2, but of course you need NOT get the sync to sub-millisecond values.