Several newer developments gave me hope that acceptable MySQL performance could be attained:
- 4,000 Provisioned IOPs - With the May 2013 introduction of 4k pIOPs EBS volumes, EC2 instances could finally be configured with persistent storage (as opposed to ephemeral storage) fast enough for RDBMS performance.
- cc2.8xlarge - this monstrosity provides 60GB of RAM, 32 virtual CPUs, and 10 gigabit networking. Since implementing this, AWS added the c3.8xlarge for the same price- running the next generation of Intel Xeon with a similar configuration but with more overall compute power; but adding 2 320GB SSDs.
- MySQL threadpool - I wrote about this in my previous post. By pre-allocating a pool of threads available for handling connections, Percona Server is able to prevent the CPU from spending the majority of its cycles performing context switching.
When testing our implementation on a cc2.8xlarge with a 4k PIOPs EBS volume, I found that the MySQL Server was still unable to handle the query load necessary to migrate to AWS. In fact, queries began queueing up in the processlist and all CPU threads would spike to 100% within minutes.
Adding the threadpool support from Percona Server 5.5, I was able to successfully provide more than 600 qps of complex aggregate queries, all while CPU load remained within healthy thresholds. I did not perform extensive A / B benchmarking for this problem, but it would seem that the overhead added to CPU scheduling by the EC2 hypervisor makes it much more likely to overload under MySQL's workload.