Everything was stood up using Terraform, the benchmark tests were conducted using Sysbench, and all data was plotted using R.
Since we didn't have access to Google's original data, we provided some overlays in the post as an easy visual comparison. However the data used to produce all of those graphs as well as additional data is in the repo.
> The claim that low thread counts are typical for web applications (and thus what people should focus on) is inaccurate. There are a large number of AWS customers who run applications using Aurora, and it is very common for them to run with hundreds of threads (and many customers choose to run with thousands).
For your typical web application, you do have very low thread counts, and you usually get parallelization through multiple instances of the web application (in my case, an API).
Can you really assume your app server and your database are in the same Availability Zone? I would expect to have app servers spread across different AZs.
If you take a look at the data, I tested the database in cross-az functionality as well. Still better reports than what Google has shown in their benchmark. The only thing I can gather is they were testing from an instance on Google's platform.
https://cloudplatform.googleblog.com/2016/08/Cloud-SQL-Secon...
The results they posted didn't exactly mirror what we saw.
You can get the raw data without the "Gated" access page too. https://github.com/2ndWatch/aurora_benchmark
Everything was stood up using Terraform, the benchmark tests were conducted using Sysbench, and all data was plotted using R.
Since we didn't have access to Google's original data, we provided some overlays in the post as an easy visual comparison. However the data used to produce all of those graphs as well as additional data is in the repo.