Earlier this week, Amazon announced that Amazon Aurora is generally available on Amazon RDS. The Aurora website promises a lot:
Amazon Aurora is a MySQL-compatible, relational database engine that combines the speed and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases. Amazon Aurora provides up to five times better performance than MySQL at a price point one tenth that of a commercial database while delivering similar performance and availability.
Here at Alfresco, my colleagues have been playing around with Aurora too – actually Alfresco is mentioned as a partner on the announcement article above, so ‘playing’ is probably not the right word ;-). But anyway, the noise I’ve heard coming from that team has been quite positive. Since we’ve just published the results of running our performance benchmark on (amongst others) Oracle on Amazon RDS, trying out the benchmark on Aurora was a no-brainer.
I’ve added the benchmark results to the sheet of the previous performance blog post: https://docs.google.com/spreadsheets/d/15wK7dQfgChz-9XF1qYi0qMnNoRWp4FQQr6XTYHXTHEE/edit#gid=739564290. The sheet compares the numbers from Oracle on RDS vs Aurora on RDS.
We selected the same hardware as the benchmark on Oracle RDS. Remember from my previous post that I couldn’t get MySQL to perform as expected on RDS (hence why I switched to Oracle on RDS, which surely is pricier!). Luckily, Aurora doesn’t seem to suffer the same fate as it’s MySQL nephew 🙂
So here’s what we saw: when using just a single thread, the numbers weren’t that clear. Half of the use cases performed better on Oracle, the other half better on Aurora. On average, Aurora was 16.96% faster for the same benchmark on Oracle. However, our test with the most data (service tasks vars 02), which is hard to see on the chart due to the scale, performed 50% better.
When we add more threads to the system to execute processes, we see a clear pattern arise. The more threads we added, the better the results for Aurora became. With ten threads (the most we tested), Aurora is faster in all but two cases (which does makes me want to check upon those tests, cause they are measured in a different way), and in general 25% faster.
Lastly, we tested the random execution (2500 random process instance executions), which comes close to a real system with real processes running on it. The graph clearly shows that Aurora beats Oracle for this test. On average, we saw a 20% better performance of Aurora:
Although we didn’t got the five times performance improvement from the marketing announcement (EDIT 31st July 2015: as pointed out in the comments below, the ‘up to five times’ is for MySQL and NOT for commercial databases. Which matches what we saw.), I was genuinely surprised that, with the same hardware and setup, Aurora is 20% faster on average with outliers up to 81%. Also note that our benchmark is really write-intensive, where Aurora makes setting up read replica’s a breeze through the AWS console. So probably for other benchmarks, with a bit more reads, Aurora can shine even more.
Also cost-wise, Aurora is interesting. I checked the bill: Oracle was about 1.96$/hour while the Aurora machine I was using is advertised at 1.28$.hour (couldn’t verify, as it shows as 0$ on the bill currently … maybe a promotion?). So more performance for less money … who doesn’t like that!
When it comes to Activiti, the conclusion is still the same: Activiti is highly performant and scalable. A faster database just makes that event better 🙂