Google Cloud SQL is slow

Question

I have a D0 size Cloud SQL instance. When I run a simple

select * from table

which has around 500 rows, it takes on average 100 ms to execute (as reported by SQL Prompt). Whereas on my local instance of MySQL 5.5, it takes only 1 ms. My dev machine has 2.9GHz dual-core Intel Core i7 and 8GB 1600MHz memory. I've read in an FAQ that performance of db depends on the size - larger instances have more RAM and CPU.

Is this reasonable to expect performance issues resolved with larger instance size? Or am I missing something else here?

Answer 1

Views were the cause of poor performance. Google runs their own flavor of MySQL engine which is optimized in a way that can hurt views. If you have many joins or/and unions expect views to run slow.

However, it's been almost a year since I posted this question and things might have changed. I haven't revisited views since we moved away from using them.

Answer 2

Here's our update in January/2019.

Using Google Cloud SQL SECOND GENERATION with a 46GB database in a 4vcpu + 15GB RAM instance, we found it can be ridiculously slow even when compared to a dev macbook pro running the default mysql install with only 125MB of memory allocated to it:

Mysql: Google Cloud SQL with 10GB RAM is 20x slower than Macbook Pro configured with 125MB ram

Answer 3

EDIT: April 10 2016

GAE now offers Second Generation cloud mysql where even a basic tier like 'db-g1-small' performs as fast as a D8 tier in the old Cloud SQL offering. It is also significantly cheaper. This seems to be a big milestone and there is no reason to resort to hacks and workarounds any longer.

You can refer to Cloud SQL pricing but the approximate minimum cost is around $20 per month.

ORIGINAL POST

Google just provisions the VM on a slow box for the D0 tier. You could choose D4 but RAM is not the main issue as much as the processor (they don't mention the GHz).

Network latency is not the problem. For e.g. the 0.05s below is the query execution time on the server only. Any amount of time thereafter could be spent in data transmission.

mysql> select * from tracking limit 5;
+--------------------------------+-----------+-----------+
| id                             | scan_date | status    |
+--------------------------------+-----------+-----------+
| 420006929400111899561510697350 | NULL      | Delivered |
| 420010859400111899561989496058 | NULL      | Delivered |
| 420019849400111899561989496331 | NULL      | Delivered |
| 420100109400111899561903290311 | NULL      | Delivered |
| 420100319400111899561944407020 | NULL      | Delivered |
+--------------------------------+-----------+-----------+
5 rows in set (0.05 sec)

Edit: March 2016

For several apps I no longer use Cloud SQL and use a remotely hosted basic MySql cluster instead since GAE opened outbound socket connections. Sounds crazy? Not according to the numbers - sending a query and getting data back over this socket connection is faster than a co-located D3.

Answer 4

1. Where are you connecting to your Cloud SQL instance from?
2. The tier size will have a big effect on performance. You can change the tier of the instance temporarily to test it.

Answer 5

We also had the same problem. With a D16 instance, a simple website forum page would take >10s to load. I just talked with a GoogleCloud tech-support engineer, who confirmed that CloudSQL is not really ready for "performance" (as of summer 2015), and he recommended rewriting everything to use DataStore...

So, if you have pages that make dozen of small SQL queries, and a dataset that's too big to fit entirely in the cache, then CloudSQL is not a viable solution right now.