Should I increase concurrency via app.yaml when using cloud SQL?

51 views
Skip to first unread message

Sam

unread,
Sep 19, 2016, 10:43:07 AM9/19/16
to google-appengine-go
The docs say an app (standard) can have up to 8 concurrent connections before launching new instances, but an instance can't have more than 12 connections open to cloud sql (I'm using generation 2). So can I increase my concurrency to 12? 
What would happen if I boost it to let's say 20? My app would be returning DB connection errors but no new instances would launch? If that's the case, is there a way for my app to send some type of error code to force the launch of a new instance?

Thanks!

Ronoaldo José de Lana Pereira

unread,
Sep 19, 2016, 10:53:35 AM9/19/16
to Sam, google-appengine-go
My understanding is that you could keep the sql.Db connection as a package-level variable (hence, one per instance), since this object is concurrently safe to access from multiple go routines or requests (this is how I'm handling connections at the moment).

The issue is when App Engine scales your app up to have more than 12 instances, and that would generate more connections than you can handle in the current tier. I believe that the 13th instance will not be able to open a new connection and you will get a dial error.

You can fix the upper bound for instance startup using basic scaling. Another approach is to release the connections instead of retain them, as recommended somewhere by App Engine docs. I'm not sure about latency for opening connections using the cloudsql proxy (which App Engine uses under the hood to talk to both SQL generations).

Either way, due to the nature of how the SQL connections are managed, you always have an upper bound of connections for the database tier. You can increase it by upgrading your tier, which would be a necessity either way because more connections may indeed require more CPU/memory/IOPS. However, this is non-automatic process, and very application specific.

--
You received this message because you are subscribed to the Google Groups "google-appengine-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine-go+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Ronoaldo Pereira

Sam

unread,
Sep 19, 2016, 12:14:45 PM9/19/16
to google-appengine-go
Hmm, I understood it differently. I use a global/package level sql.DB as you mentioned and under the hood per instance it will pool this into multiple connections with a max of 12, that's according to these docs:


Each App Engine instance running in a standard environment or using Standard-compatible APIs cannot have more than 12 concurrent connections to a Google Cloud SQL instance.

And since concurrent connections are up to 4000 on generation 2, I could have 4000 / 12 = 333 instances running??

Ronoaldo José de Lana Pereira

unread,
Sep 19, 2016, 2:06:27 PM9/19/16
to Sam, google-appengine-go
This is interesting. Although that docs don't mention any pooling from the appengine/cloudsql package itself, it may be the case that they do that in the cloudsql proxy program that exposes a socket-like file descriptor to your app engine instance.

This is, however, easy to diagnose: just deploy a "connection test" program as an alternative, non-default version/module and load it with some Apache Bench HTTP requests concurrently. From my observations, the package-level persistent connection represents a single connection to the database; if you see more connections than instances, then there is a pooling in place.

Either way, your math is the theoretical maximum. Since the pooling is somewhat out of your control, you can trust in this maximum as a basis to your planing. I believe that your app will do very very well in Go with way lower instances, to be honest, specially with 12 concurrent requests per instance.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine-go+unsubscribe...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Ronoaldo Pereira

--
You received this message because you are subscribed to the Google Groups "google-appengine-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine-go+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Ronoaldo Pereira
Reply all
Reply to author
Forward
0 new messages