Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Wasting Connections, Use HTTP Keep-Alive

lob.com

Post reply on HN
Print view View original

71–80 of 112 posts

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#71

Post by cm2187 »

RussianCow wrote: post #44
0xbadcafebee wrote: post #32

Earlier quoted context omitted.

Of all the micro-optimizations I could think of for web apps, the one with the highest cost and the least benefit would probably be supporting http2 (or *quic). In almost all cases, there is a fix that will speed up http1.1 to acceptable levels.

What's the "cost" to supporting HTTP 2 as an app developer, though? As far as I know, adding support to nginx requires changing one line of code. That's about as close to free as you can get.

Server push can’t be free. You need the web server to somehow know what resources will be required by the page and I still don’t understand how it doesn’t defeat browser caching but I presume it must involve some non trivial configuration.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#72

Post by teddyh »

baroffoos wrote: post #18
hkolk wrote: post #5

Better yet.. switch to http2 (where keep-alive is deprecated): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ke...

Its amazing that not everyone is on http2 yet when its basically free speed.

Well, mod_http2 is incompatible with mpm-itk, and while it’s possible to run nginx as a front-end proxy, such a solution has its own complexities making it not really worth it in most cases where speed is not a top requirement.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#73

Post by johncolanduoni »

cm2187 wrote: post #71
RussianCow wrote: post #44

Earlier quoted context omitted.

What's the "cost" to supporting HTTP 2 as an app developer, though? As far as I know, adding support to nginx requires changing one line of code. That's about as close to free as you can get.

Server push can’t be free. You need the web server to somehow know what resources will be required by the page and I still don’t understand how it doesn’t defeat browser caching but I presume it must involve some non trivial configuration.

Server push also isn’t required to reap most of the benefits. In the places where I’ve tried it I’ve not seen any benefit over link preload headers + HTTP2 without push. Many CDNs that support HTTP2 haven’t bothered to support server push at all, I suspect due to the limited advantages compared to the extra complexity.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#74

Post by zaarn »

cm2187 wrote: post #71
RussianCow wrote: post #44

Earlier quoted context omitted.

What's the "cost" to supporting HTTP 2 as an app developer, though? As far as I know, adding support to nginx requires changing one line of code. That's about as close to free as you can get.

Server push can’t be free. You need the web server to somehow know what resources will be required by the page and I still don’t understand how it doesn’t defeat browser caching but I presume it must involve some non trivial configuration.

Your webapp needs to start the push, browsers will interrupt it if they find the resource is already in cache after it has parsed the HTML.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#75

Post by johncolanduoni »

RussianCow wrote: post #61
peterwwillis wrote: post #45

Earlier quoted context omitted.

For a tiny startup, you might be able to just add http2 support in 10 minutes and everything might be fine, but most of the time it's more complicated. It's a bit like if I said, can I change your app libraries to bleeding edge? It's just a one line change.

Could you be more specific, though? What's more complicated? I'm legitimately curious because I know very little about HTTP 2, but at work (not a tiny startup) we recently enabled it and it turned out to be a trivial change. Unless you're implementing the networking layer of your backend yourself, it seems like a change with practically no cost or tradeoff, as long as your server software supports it.

One thing I’ve ran into is misconfigured native apps who accidentally treat headers as case sensitive. In particular the usual HTTP client in iOS handles header case sensitivity for you, unless you use newer versions of Swift where it converts the custom header dictionary into a vanilla Swift one that doesn’t treat header lookups as case-insensitive :/

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#76

Post by pvg »

berkut wrote: post #70
pvg wrote: post #59

Earlier quoted context omitted.

I don't know why you're seeing what you're seeing but your testing/monitoring setup sounds like it's at a bit too low level for the thing you're trying to figure out. A few basic things you might want (or should, really, if you're implementing HTTP from scratch) to try: - Serve real content, say, a basic HTML page with a couple of external resources. - Serve same and monitor (turn on all teh logs) with apache. - Use…

Thanks, but I've done this (although used Nginx instead). The web server I've written is now serving several websites I'm hosting, some of which have thousands of images, so there's plenty of scope for connection re-use. Each connection ID is different within dev tools in Chrome - although errors have 0 - (often sequential, sometimes there are huge gaps). And this is the same with HTTP websites on the net (just tried…

'Too low level' is Wireshark before Chrome dev tools. I didn't know if you'd tried the dev tools since you didn't mention it. As to the other stuff, I'm not sure what portable Chrome-breaking field you emit - www.briscoes.co.nz instantly shows connection reuse on my end.

https://i.imgur.com/LJIaRac.png

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#77

Post by Ayesh »

merb wrote: post #26
hkolk wrote: post #5

Better yet.. switch to http2 (where keep-alive is deprecated): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ke...

of course, because http2 is stateful and whenever the server or client whishes, they can send a close message. but stateful connection management comes with a cost, especially on tcp.

> but stateful connection management comes with a cost, especially on tcp.

Keep-alive isn't any better. In Apache bad nginx, keep-alive and http/2 parallel requests are handled at a separate thread and hardly adds any noticeable load.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#78

Post by merb »

bluejekyll wrote: post #35
merb wrote: post #26

Earlier quoted context omitted.

of course, because http2 is stateful and whenever the server or client whishes, they can send a close message. but stateful connection management comes with a cost, especially on tcp.

What do you mean by stateful in this context? Http/2 is multiplexed, unlike http/0.9-1.1, and while that has some overhead, it being a binary protocol probably makes up for it.

The whole protocol has state, because that's the only way to multiplex multiple data streams over a single connection.

i.e.: https://http2.github.io/http2-spec/#StreamStates of course the "user layer" is stateless, but the whole connection handling is a state machine (which actually http/0.9-1.1 wasn't)

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#79

Post by throwaway9d0291 »

abledon wrote: post #28
hkolk wrote: post #5

Better yet.. switch to http2 (where keep-alive is deprecated): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ke...

Is it easy for Django/Rails/ExpressJS to implement Http2 in their next release?

Django doesn't implement HTTP (except for the development server), that's up to whatever's handling WSGI, like uWSGI or Gunicorn or something.

Unfortunately neither of those currently support HTTP2.

For serving Python, I think your best bet right now is uWSGI behind NGINX.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#80

Post by h1d »

irrational wrote: post #63
RussianCow wrote: post #61

Earlier quoted context omitted.

Could you be more specific, though? What's more complicated? I'm legitimately curious because I know very little about HTTP 2, but at work (not a tiny startup) we recently enabled it and it turned out to be a trivial change. Unless you're implementing the networking layer of your backend yourself, it seems like a change with practically no cost or tradeoff, as long as your server software supports it.

I imagine its more bureaucratic complexity than technical. This change would require lots of committee meetings, reviews, meetings, discussions, etc. at my company. It would probably take a year to decide to do it and 5 days to actually do it (Get all IT groups into a large war room, make the change on dev servers and then everyone has to completely test all their apps and sign off on it. Then do it again on staging.…

How do you get your work done when 1 line change takes so long.
Post reply on HN