Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce default idle timeout? #276

Closed
ronag opened this issue Jul 30, 2020 · 11 comments · Fixed by #279
Closed

Reduce default idle timeout? #276

ronag opened this issue Jul 30, 2020 · 11 comments · Fixed by #279
Labels
question [Use a Discussion instead]

Comments

@ronag
Copy link
Member

ronag commented Jul 30, 2020

https://aws.amazon.com/about-aws/whats-new/2017/03/announcing-configure-read-timeout-and-keep-alive-timeout-values-for-your-amazon-cloudfront-custom-origins/

Cloudfront seems to default to 5 seconds. Might be safer for us to default to something like 2-3 seconds?

@mcollina @szmarczak Thoughts?

The keep-alive idle timeout value specifies the maximum amount of time that CloudFront will maintain an idle connection with a custom origin server before closing the connection. The default keep-alive idle timeout value is 5 seconds, but you can now configure a higher value up to 60 seconds.

@ronag
Copy link
Member Author

ronag commented Jul 30, 2020

Might not be a huge perf impact after #275. Assuming servers implement it.

@szmarczak
Copy link
Member

Cloudflare:

Ensure HTTP Keep-Alive connections are enabled on your origin. Cloudflare reuses open TCP connections for up to 15 minutes (900 seconds) after the last HTTP request. Origin web servers close TCP connections if too many are open. HTTP Keep-Alive helps avoid premature reset of connections for requests proxied by Cloudflare.

@szmarczak
Copy link
Member

@ronag
Copy link
Member Author

ronag commented Jul 30, 2020

Wow, that's a large difference in policy... though I think we might have to aim for worst case?

Or should we have some kind of lookup list for known CDNs?

@ronag
Copy link
Member Author

ronag commented Jul 30, 2020

Would be nice to have some kind of test urls to see whether or not they set the keep-alive header.

@szmarczak
Copy link
Member

szmarczak commented Jul 30, 2020

@ronag ronag added the question [Use a Discussion instead] label Jul 30, 2020
@szmarczak
Copy link
Member

Might be safer for us to default to something like 2-3 seconds?

That's definitely not enough. IMO it should default to 60s at least... I mean it depends on how often you query the server. It's hard to say.

@ronag
Copy link
Member Author

ronag commented Jul 30, 2020

You can always override it... I think that by default we should be as compatible as possible. Within reason.

Seems like cloudfront is a bit of an edge case at the moment. Would be very interesting to see whether they provide keep-alive hints or not... haven't been able to find any test url.

@ronag
Copy link
Member Author

ronag commented Jul 30, 2020

Sad.

curl -vv --http1.1 https://d3h26nxsv4jv3l.cloudfront.net/image/320/two-yellow-labrador-retriever-puppies-1108099.jpg
*   Trying 13.33.20.150...
* TCP_NODELAY set
* Connected to d3h26nxsv4jv3l.cloudfront.net (13.33.20.150) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=Washington; L=Seattle; O=Amazon.com, Inc.; CN=*.cloudfront.net
*  start date: May 26 00:00:00 2020 GMT
*  expire date: Apr 21 12:00:00 2021 GMT
*  subjectAltName: host "d3h26nxsv4jv3l.cloudfront.net" matched cert's "*.cloudfront.net"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert Global CA G2
*  SSL certificate verify ok.
> GET /image/320/two-yellow-labrador-retriever-puppies-1108099.jpg HTTP/1.1
> Host: d3h26nxsv4jv3l.cloudfront.net
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: image/jpeg
< Content-Length: 11942
< Connection: keep-alive
< Date: Thu, 30 Jul 2020 13:02:30 GMT
< Last-Modified: Wed, 11 Mar 2020 03:25:28 GMT
< ETag: "5c26029979fa5f2f1ca8cb4077069141"
< x-amz-meta-original_key: two-yellow-labrador-retriever-puppies-1108099.jpg
< Accept-Ranges: bytes
< Server: AmazonS3
< X-Cache: Hit from cloudfront
< Via: 1.1 dfc0196c9ed9e207c1ca13a43e7783b8.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: ARN53
< X-Amz-Cf-Id: cV3h_KTS9GsDbtJnryx6bR-zbYxhvHz2wo-lnagwa_Jq22cyTi592Q==
< Age: 66
< 

@ronag
Copy link
Member Author

ronag commented Jul 30, 2020

https://forums.aws.amazon.com/thread.jspa?threadID=325450

@ronag
Copy link
Member Author

ronag commented Jul 30, 2020

@szmarczak Actually, I think node also has 5s as default keepAliveTimeout... https://github.com/nodejs/node/blob/master/lib/_http_server.js#L369

ronag added a commit that referenced this issue Jul 30, 2020
Node HTTP server seem to have a default of 5 seconds and
we should be below that.

Fixes: #276
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question [Use a Discussion instead]
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants