[cbushko]

CloudSQL was slow for us until we do the following:

  1) Increase the disk size to 100GB as this increases the IOPs
  2) Switch to using private IP addresses. Huge speed increase
  3) get rid of cloudsql-proxy. Another huge speed increase

These 3 things have kept our database instances very small and costs low.

[ransom1538]

3) get rid of cloudsql-proxy. Another huge speed increase

^ Do not use cloudsql-proxy ever. GCP docs are wrong. DO NOT proxy all your db requests through a single VM.

[cbushko]

Ours cloudsql-proxies were on running on GKE so they were not "that bad".

Switching to private ip definitely had the largest impact by far on performance.

[DangitBobby]

If you need very high throughput I can appreciate this advice. Generally though, cloudsql-proxy is fast enough for most use-cases.

[nlightcho]

What about running it as a sidecar in the backend pods?

[lukeschlather]

This causes some other problems... Kubernetes doesn't do a very good job of treating the sidecar as part of the main container so you will get random disconnects in your app when the proxy is restarted unexpectedly. This is actually why we abandoned it, just to deal with the random hiccups. Hadn't even benchmarked it.

[stevencorona]

Yeah, have hugely over provisioned disks for IOPS. Am still using public ip + cloudsql-proxy because the alternative didn't exist when I first deployed, but I'll try switching.

[cbushko]

I went through this during last summer. The nice thing is that you can switch to private ip and cloudsql-proxy will still work. At least you can isolate your changes.

[sa46]

> Switch to using private IP addresses. Huge speed increase.

Interesting. I'm looking Cloud SQL right now and the advice seems to lean in the opposite direction: use public IPs for ease of connecting. Can you quantify the decrease in latency? All I can find is bits about reduced network hops.

[cbushko]

I honestly don't know what the difference is but the number of hops is probably a contributing factor to the decrease in speed. There could be some translation layer happening when going from the CloudSQL instances private IP to public IP with some security checks that slow it down.

I didn't have to worry about the 'ease of connecting' when using CloudSQL as all my GCP services are in the same VPC.

Also, private ip is one less security problem to worry about.

[lukeschlather]

Is it speed of establishing a connection or does it affect pooled connections? What database engine are you using?

We abandoned cloudsqlproxy partially because the sidecar in Kubernetes caused random disconnects, but also because it just had bizarre network errors sometimes. (That was mostly when connecting from outside GCP though.)

[cbushko]

We are using PHP and thus no connection pools at all. This definitely doesn't help us with speed. With public IP there was some mystery point that just slowed everything to a crawl.

MySQL for our DB.