Cloud Functions -> Cloud SQL via Socket Factory too slow

[Hans Ravnaas]

So I'm connecting from Cloud Functions for Java in us-central1 to Cloud SQL (postgres 11) in us-west1 using the socket factory approach ('com.google.cloud.sql:postgres-socket-factory:1.0.13'). Everything works, but it takes around ~10 seconds to first obtain the connection, which is the problem. I am spanning two locations, but I didn't think it'd make that much of a difference. Here are the key log entries and the amount of time each one takes. Is this inline with what everyone else is seeing too? I haven't tried creating my own client cert yet but was hoping to avoid managing that.

• 6 ms:  INFO: Connecting to Cloud SQL instance [projectid:us-west1:instancename] via SSL socket.
• 7 sec: INFO: First Cloud SQL connection, generating RSA key pair
• 3 sec: INFO: Obtaining ephemeral certificate for Cloud SQL instance [projectid:us-west1:instancename]...
• 1 sec: INFO: Connecting to Cloud SQL instance [projectid:us-west1:instancename] on IP [public ip].

Any insight appreciated.

Hans

[Kurtis Van Gent]

Hey Hans,

That is much higher latency than I would expect to see with the socket factory. 

In the meantime, you can try setting the env var `CLOUD_SQL_FORCE_UNIX_SOCKET=true` to see if that improves the situation. This takes advantage of the `/clousql` unix socket that is provided to functions environments. 

Please let me know if that works for you.

Thanks,

Kurtis

[Hans Ravnaas]

Hi, Kurtis

Thanks for the suggestion. I did try that on Friday, and even though the log showed the setting took effect, it didn’t change things for the better.

Sent from my iPhone

--
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-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/85386faa-3a78-4d0a-905c-6019145f55cf%40googlegroups.com.

[Tiago (Google Cloud Platform Support)]

Hello Hans,

It seems that Kurtis has submitted an open issue on your behalf for this in the 'cloud-sql-jdbc-socket-factory' GitHub repository. I'd suggest to add any relevant information and findings you might have gathered from your specific use cases in that thread as well.

On Monday, May 27, 2019 at 11:37:25 PM UTC-4, Hans Ravnaas wrote:

Hi, Kurtis

Thanks for the suggestion. I did try that on Friday, and even though the log showed the setting took effect, it didn’t change things for the better.

Sent from my iPhone

On May 27, 2019, at 4:51 PM, 'Kurtis Van Gent' via Google Cloud SQL discuss <google-cloud-sql-discuss@googlegroups.com> wrote:

Hey Hans,

That is much higher latency than I would expect to see with the socket factory. 

In the meantime, you can try setting the env var `CLOUD_SQL_FORCE_UNIX_SOCKET=true` to see if that improves the situation. This takes advantage of the `/clousql` unix socket that is provided to functions environments. 

Please let me know if that works for you.

Thanks,

Kurtis

On Sunday, May 26, 2019 at 11:37:18 AM UTC-7, Hans Ravnaas wrote:

So I'm connecting from Cloud Functions for Java in us-central1 to Cloud SQL (postgres 11) in us-west1 using the socket factory approach ('com.google.cloud.sql:postgres-socket-factory:1.0.13'). Everything works, but it takes around ~10 seconds to first obtain the connection, which is the problem. I am spanning two locations, but I didn't think it'd make that much of a difference. Here are the key log entries and the amount of time each one takes. Is this inline with what everyone else is seeing too? I haven't tried creating my own client cert yet but was hoping to avoid managing that.

• 6 ms:  INFO: Connecting to Cloud SQL instance [projectid:us-west1:instancename] via SSL socket.
• 7 sec: INFO: First Cloud SQL connection, generating RSA key pair
• 3 sec: INFO: Obtaining ephemeral certificate for Cloud SQL instance [projectid:us-west1:instancename]...
• 1 sec: INFO: Connecting to Cloud SQL instance [projectid:us-west1:instancename] on IP [public ip].

Any insight appreciated.

Hans

--
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+unsub...@googlegroups.com.

[Kurtis Van Gent]

Hi Hans,

We released v1.0.14 of the Cloud SQL JDBC Socket Factory today. It contains several performance improvements, including some improvements for functions. Please give it a try and let me know how it goes.

Thanks,

Kurtis

On Wednesday, May 29, 2019 at 9:56:28 AM UTC-7, Tiago (Google Cloud Platform Support) wrote:

Hello Hans,

It seems that Kurtis has submitted an open issue on your behalf for this in the 'cloud-sql-jdbc-socket-factory' GitHub repository. I'd suggest to add any relevant information and findings you might have gathered from your specific use cases in that thread as well.

On Monday, May 27, 2019 at 11:37:25 PM UTC-4, Hans Ravnaas wrote:

Hi, Kurtis

Thanks for the suggestion. I did try that on Friday, and even though the log showed the setting took effect, it didn’t change things for the better.

Sent from my iPhone

[Hans Ravnaas]

Hi, Kurtis

Thanks for the fix. I just tested it. It now automatically uses the unix socket as expected but I'm still seeing it log "INFO: First Cloud SQL connection, generating RSA key pair". During my run, generating the key pair took ~3 seconds, so still slow. I was under the impression that that step would be skipped? But I certainly don't know enough about what goes on behind the scenes there to claim that it should be skipped.

Another minor thing, the readme at https://github.com/GoogleCloudPlatform/cloud-sql-jdbc-socket-factory could probably be updated to include a mention for Functions, so something like...

"The library will automatically detect when it is running on GAE Standard and Cloud Functions, and will connect via the provided unix socket for reduced latency."

Hans

[Kurtis Van Gent]

Hi Hans,

I was just able to confirm this was an oversight on my part that only effects the postgres module. I've opened a PR to address it (#146).

Thanks,
Kurtis