Advatronix Cirrus 1200: a Storage Server Under Your Desk

Low Latency Database Servers

The main usage case for the Cirrus 1200 is serving up documents and files, basically a "NAS on steriods". Ganesh specializes in this field, so we'll leave that evaluation to him. There is little doubt in our mind that the combination of quad "big core" Xeon (compared to a much weaker ARM or Atom cores), the relatively high performance RAID-controller, and the large amount of memory should make the Cirrus 1200 a very potent file server, especially compared to the usual NAS solutions that rely on much slower ARM SoCs, Atoms, or Celerons. Most of them also have just 1-4GB of RAM. But as a file server, the Cirrus 1200 is likely overkill.

As we explained in the introduction, we believe that one of the use cases for the Cirrus 1200 is as a high performance database server, potentially combined with a file server. The idea is that you are in full control of your data (i.e. it's not in the cloud), and you can offer low latency (network) access without hosting costs. Most databases are storage limited, so the availablility of 10 (12 in total) hard drives and 6 SSDs sounds very good in that respect. The other technical specifications (Xeon E3, 32GB max) are not ideal for a database server, but they typically aren't as critical. Thus it seemed that it would be very interesting to see what this platform was capable of as a database server, and what would be the best way to configure it.

We used HammerDB to set up a "tpcc-like" database, but we tested the transactions rate with our vApus stress test, as it is more accurate and closer to the real world than the classic "HammerDB" test. It also allows us to integrate extensive monitoring while testing, which can improve our understanding of what is going on. Also, throughput (transactions per second) should not be reported without taking response time into account. We tested with 128 to 1024 connections and report the throughput numbers that—at most—require a response time of 100 ms. We chose this number as a typical database application will do quite a few requests to the database. A 100 ms transaction response time should deliver acceptable application response times (< 1 second).