undefined | Better HN

0 pointsyoungtaff10y ago0 comments

From memory request pipelining is disabled in most browsers as many intermediaries (proxies etc) screw it up, it's still vulnerable to head-of-line blocking even when it's enabled.

You'd be surprised how many servers don't have keep-alive enabled, it's much more common than I'd like.

I'm a great fan of HTTP/2 but I'd like to see realistic tests!

0 comments

6 comments · 3 top-level

bsdetector10y ago· 2 in thread

There has been one realistic test that I know of, done by Microsoft Research, and they found pipelining to be basically equivalent to HTTP/2.

But that doesn't fit the narrative. Did Google ever test against pipelining? Did IETF? No, they didn't. Did Google ever show the effect of head-of-line blocking on page load speed, especially when spread over several independent TCP connections? No, they didn't. Why didn't they do this basic research before pushing their new protocol?

They just said "it's 40% faster! rubber stamp this because it's in Chrome!" and some of their fans even created stacked demos where pipelining wouldn't be used (perhaps unintentionally, but still invalid comparisons).

youngtaffOP10y ago

Is it this paper - http://research.microsoft.com/pubs/170059/A%20comparison%20o...

I think if you read back though people like Will Chan's and others blogs it becomes clear that pipelining doesn't work reliably enough outside a test lab environment plus HoL blocking is still an issue for it

bsdetector10y ago

"Doesn't work reliably enough" doesn't answer the question of why Google didn't test HTTP/2 against pipelining. None of Google's performance improvement claims compared to pipelining, and they've never demonstrated or quantified an actual real-world head of line blocking problem (ironically, other than Google Maps loading very slowly in HTTP/2 because of a priority inversion).

Will Chan is the guy that wrote "it’s unclear what these intermediaries are". Oh well, there's some bad software out there, let's just make a whole new protocol /s. Fix the bad software, or at least find out what it is. If it's malware causing the problems, you don't need to make a whole new protocol you can just get rid of the malware.

vardump10y ago· 1 in thread

Yup, and clients also mess it up, especially when it comes to pipelining. Should also not forget about TLS session resumption. I've seen it boost server performance over 10x, TLS session negotiation is CPU bound.

youngtaffOP10y ago

I didn't even check if they were using session resumption, OCSP stapling etc., I thought I'd found enough shortcomings for now

merb10y ago

mostly keep-alive could be worse when only a few requets run

j / k navigate · click thread line to collapse

0 comments