I've been experimenting with using Cloud SQL Proxy for my PostgreSQL database vs. connecting directly via TCP. To illustrate, here's my Stackdriver Trace latency graph:
Around 18:15 I switched from directly connecting via TCP from GKE to Cloud SQL over to using a Cloud SQL proxy sidecar that my service connects to via a Unix socket (connecting to the proxy via TCP yields very similar results). As one can see, there are a few spikes in latency when the connection pools get warmed up, and then the latency distribution is significantly above the latency before, which was for direct connections.
My Stackdriver Trace spans also indicate that the increase in overall latency can be attributed to an increase in database call latency. Trivial database calls that normally take <=10ms via a direct connection take up to 100ms through the proxy.
Is this expected, can I do anything about it, and, if there is no remedy, what would be the best way to connect to the DB via TCP from GKE? I'm currently using a /16 netmask to allow connections grom GCE, but that's probably bad for production. Also, I'm not sure whether direct traffic to Cloud SQL is encrypted — if you could provide insights into that, that would be appreciated.
FYI, the GKE cluster and the Cloud SQL database are located in the same zone (europe-west3-a IIRC). The database is only ~500 MB right now (fits completely into memory and has appropriate indexes) and has low load. Also, as stated above, I am using connection pooling and have confirmed that that works.
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/cf85e7f0-5e2e-4b55-aaab-6d9228a0aaab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment