5 ms·

If you want an easy speed up and you use a modern version of nginx, which you should for many reasons but chiefly performance and security. Add these lines to

If you want an easy speed up and you use a modern version of nginx, which you should for many reasons but chiefly performance and security. Add these lines to your nginx config file: # Only support HTTPS and enable http2 # which will allow you to multiplex requests. # In a separate config do a 301 from normal HTTP # for all paths / subdomains. listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; # Make TCP send multiple buffers as individual packets. tcp_nodelay on; # Send half empty (or half full) packets. tcp_nopush on; It reduced our page load time by around 75%, and more for people accessing the site from the other side of the world.

jstanley 9y ago
I just tried this and was unable to measure any difference. Variation in page load times far outweighed any difference the config change might have brought. So, YMMV. From a theoretical standpoint I agree http/2 should help (although in practice I didn't measure any difference). I can't see why tcp_nodelay would help except in extremely niche applications (sending tiny responses with lots of pauses?)
- DamonHD 9y ago
  My evidence is that HTTP/2 doesn't help much if at all for lightweight sites, especially if the site manages to hit my target of the first 10kB hitting the client rendering all the above-the-fold information, and especially if the clients are reasonably close to the server. Indeed, given that HTTP/2 forces TLS (for any mainstream browser) which forces an extra RTT, for light pages my evidence is that HTTP/2 makes things marginally worse... http://www.earth.org.uk/note-on-carbon-cost-of-CDN.html http://www.earth.org.uk/note-on-carbon-cost-of-CDN.html
zucchini_head 9y ago
I'm not very experienced with these nginx settings. Could you explain how this improves speed so much for you? It seems that you've followed [1] by the similarity of what that suggests to what you've suggested. tcp_nodelay seems to force it to not wait 0.2 seconds, which nginx does so that it doesn't send lots of really small packets. I can see this increasing speed by 200ms (a lot) but increases network traffic as a cost. tcp_nopush seems to be about optimising each packet sent, reducing the total size of them. Interesting stuff though! [1] https://t37.net/nginx-optimization-understanding-sendfile-tcp_nodelay-and-tcp_nopush.html https://t37.net/nginx-optimization-understanding-sendfile-tc...
- 3pt14159 9y ago
  So I'm more of a machine learning / cyber security guy than a sys admin, but with that proviso, here is my understanding: Of course you'll have to check your own site for your own performance issues, but while travelling from Toronto to Vilnius I found our site much slower and investigated why. We have a webapp running Ember with mix of largish assets, like images, and smallish assets, talking to a JSON API standard API written in rails and proxied through nginx (responses are usually around 1kb of JSON, but this gets compressed with HTTP2). In reality waiting 200ms is an enormous cost and carries a hidden cost: Larger packets are easier to lose. If you're going mostly to browsers that is more and more often going through wifi or cell tower networks with at least 1% packet loss and when the resend happens you're stuck with that 200ms delay again. That's my understanding, but the real truth is "it just works for me when testing around the world with real-world use cases, try testing it out yourself and please let me know if you learn something new".
  - the8472 9y ago
    Nagle's algorithm is not a network level delay. If data is lost then it is retransmitted as soon as the sender learns about the loss. Nagle only delays application level sends. The problem with webapps is a compounding effect of many requests. a) dependency chains (asset A loads B loads C) mean the browser only knows to load C once B has been loaded, so the latencies (including nagle) add up. http/2 push is supposed to help with that. b) statistics. your 95th percentile latency is irrelevant if you're loading hundreds of assets and want to know when the site has finished loading.
- srum 9y ago
  The horse's mouth: https://news.ycombinator.com/item?id=9045125 https://news.ycombinator.com/item?id=9045125
arlk 9y ago
Why would allowing only https result in a speedup in network? I experience that but I'm still curious about the reason.
- 3pt14159 9y ago
  Good question! By forcing HTTPS you're garunteed to get the speedups because most browsers require encryption: https://en.wikipedia.org/wiki/HTTP/2#Encryption https://en.wikipedia.org/wiki/HTTP/2#Encryption
- inapis 9y ago
  Lots of browsers force HTTPS if you want to use HTTP/2. The speedups are because of http/2 and not solely because of https.
egeozcan 9y ago
Is there similar things that can be done on a go-based server? Particularly Caddy...
- hackermailman 9y ago
  Cache everything you can. This is a good lecture on scaling a site http://15418.courses.cs.cmu.edu/spring2016/lecture/webscaling http://15418.courses.cs.cmu.edu/spring2016/lecture/webscalin...
  - DamonHD 9y ago
    Doesn't help with first page view when visiting from organic search or somewhere like HN. I do cache like it was going out of fashion, but I optimise for the first hit and assume 100% bounce rate anyway! RTT hurts in my world.
arcbyte 9y ago
HTTP2 is a garbage protocol and I continue to refuse to deploy it in our enterprise. Will wait for something else.
- icebraining 9y ago
  I didn't downvote you, but your post is content-free. Why is it a garbage protocol?
wyager 9y ago
> which you should for many reasons but chiefly performance and security. Why would you use nginx for security? I see over 100 CVEs for nginx. This isn't exactly unexpected. Nginx is an incredibly complicated piece of software written for performance in C. That's basically the trifecta of security badness. If you want security, why not use a (possibly slower) simpler product written in a safer language?
- icebraining 9y ago
  Ah, the old concept of binary security - either you want it or not. It doesn't work like that, security is one need to be balanced against others. Also, lots of CVEs indicate only one thing: that lots of people are checking it.
  - ghettoimp 9y ago
    Hrmn. Doesn't it also mean they're finding lots of problems with it?
    - throwaway135634 9y ago
      Key word "finding". Most large software has plenty of bugs, CVE's just tell you how many they're aware of
  - wyager 9y ago
    > Also, lots of CVEs indicate only one thing: that lots of people are checking it. Also that it has lots of vulnerabilities. Instead, you could use a product that's secure by design.
- rkeene2 9y ago
  If you want no CVEs you could use my web server filed[0]. It's really fast. And written in C. ;-) Of course, it doesn't support HTTPS or HTTP/2, so... there's that. [0] http://filed.rkeene.org/ http://filed.rkeene.org/

jstanley 9y ago

I just tried this and was unable to measure any difference. Variation in page load times far outweighed any difference the config change might have brought. So, YMMV. From a theoretical standpoint I agree http/2 should help (although in practice I didn't measure any difference). I can't see why tcp_nodelay would help except in extremely niche applications (sending tiny responses with lots of pauses?)

DamonHD 9y ago
My evidence is that HTTP/2 doesn't help much if at all for lightweight sites, especially if the site manages to hit my target of the first 10kB hitting the client rendering all the above-the-fold information, and especially if the clients are reasonably close to the server. Indeed, given that HTTP/2 forces TLS (for any mainstream browser) which forces an extra RTT, for light pages my evidence is that HTTP/2 makes things marginally worse... http://www.earth.org.uk/note-on-carbon-cost-of-CDN.html http://www.earth.org.uk/note-on-carbon-cost-of-CDN.html

zucchini_head 9y ago

I'm not very experienced with these nginx settings. Could you explain how this improves speed so much for you? It seems that you've followed [1] by the similarity of what that suggests to what you've suggested. tcp_nodelay seems to force it to not wait 0.2 seconds, which nginx does so that it doesn't send lots of really small packets. I can see this increasing speed by 200ms (a lot) but increases network traffic as a cost. tcp_nopush seems to be about optimising each packet sent, reducing the total size of them. Interesting stuff though! [1] https://t37.net/nginx-optimization-understanding-sendfile-tcp_nodelay-and-tcp_nopush.html https://t37.net/nginx-optimization-understanding-sendfile-tc...

3pt14159 9y ago
So I'm more of a machine learning / cyber security guy than a sys admin, but with that proviso, here is my understanding: Of course you'll have to check your own site for your own performance issues, but while travelling from Toronto to Vilnius I found our site much slower and investigated why. We have a webapp running Ember with mix of largish assets, like images, and smallish assets, talking to a JSON API standard API written in rails and proxied through nginx (responses are usually around 1kb of JSON, but this gets compressed with HTTP2). In reality waiting 200ms is an enormous cost and carries a hidden cost: Larger packets are easier to lose. If you're going mostly to browsers that is more and more often going through wifi or cell tower networks with at least 1% packet loss and when the resend happens you're stuck with that 200ms delay again. That's my understanding, but the real truth is "it just works for me when testing around the world with real-world use cases, try testing it out yourself and please let me know if you learn something new".
- the8472 9y ago
  Nagle's algorithm is not a network level delay. If data is lost then it is retransmitted as soon as the sender learns about the loss. Nagle only delays application level sends. The problem with webapps is a compounding effect of many requests. a) dependency chains (asset A loads B loads C) mean the browser only knows to load C once B has been loaded, so the latencies (including nagle) add up. http/2 push is supposed to help with that. b) statistics. your 95th percentile latency is irrelevant if you're loading hundreds of assets and want to know when the site has finished loading.
srum 9y ago
The horse's mouth: https://news.ycombinator.com/item?id=9045125 https://news.ycombinator.com/item?id=9045125

arlk 9y ago

Why would allowing only https result in a speedup in network? I experience that but I'm still curious about the reason.

3pt14159 9y ago
Good question! By forcing HTTPS you're garunteed to get the speedups because most browsers require encryption: https://en.wikipedia.org/wiki/HTTP/2#Encryption https://en.wikipedia.org/wiki/HTTP/2#Encryption
inapis 9y ago
Lots of browsers force HTTPS if you want to use HTTP/2. The speedups are because of http/2 and not solely because of https.

egeozcan 9y ago

Is there similar things that can be done on a go-based server? Particularly Caddy...

hackermailman 9y ago
Cache everything you can. This is a good lecture on scaling a site http://15418.courses.cs.cmu.edu/spring2016/lecture/webscaling http://15418.courses.cs.cmu.edu/spring2016/lecture/webscalin...
- DamonHD 9y ago
  Doesn't help with first page view when visiting from organic search or somewhere like HN. I do cache like it was going out of fashion, but I optimise for the first hit and assume 100% bounce rate anyway! RTT hurts in my world.

arcbyte 9y ago

HTTP2 is a garbage protocol and I continue to refuse to deploy it in our enterprise. Will wait for something else.

icebraining 9y ago
I didn't downvote you, but your post is content-free. Why is it a garbage protocol?

wyager 9y ago

> which you should for many reasons but chiefly performance and security. Why would you use nginx for security? I see over 100 CVEs for nginx. This isn't exactly unexpected. Nginx is an incredibly complicated piece of software written for performance in C. That's basically the trifecta of security badness. If you want security, why not use a (possibly slower) simpler product written in a safer language?

icebraining 9y ago
Ah, the old concept of binary security - either you want it or not. It doesn't work like that, security is one need to be balanced against others. Also, lots of CVEs indicate only one thing: that lots of people are checking it.
- ghettoimp 9y ago
  Hrmn. Doesn't it also mean they're finding lots of problems with it?
  - throwaway135634 9y ago
    Key word "finding". Most large software has plenty of bugs, CVE's just tell you how many they're aware of
- wyager 9y ago
  > Also, lots of CVEs indicate only one thing: that lots of people are checking it. Also that it has lots of vulnerabilities. Instead, you could use a product that's secure by design.
rkeene2 9y ago
If you want no CVEs you could use my web server filed[0]. It's really fast. And written in C. ;-) Of course, it doesn't support HTTPS or HTTP/2, so... there's that. [0] http://filed.rkeene.org/ http://filed.rkeene.org/