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

HTTP/2 technology demo

http2demo.io

Post reply on HN
Print view View original

61–70 of 100 posts

Re: HTTP/2 technology demo

#61

Post by webXL »

dijit wrote: post #13

the other server is 2x faster even without http/2 My wget implementation does not suppot http/2 HTTP Server: $ time wget https://1153288396.rsc.cdn77.org/http2/tiles_final/tile_18.png [...] real 1.038 user 0.038 sys 0.007 pcpu 5.37 HTTP2 Server: $ time wget https://1906714720.rsc.cdn77.org/http2/tiles_final/tile_18.png [...] real 0.539 user 0.045 sys 0.009 pcpu 10.01 of course that's just latency.. but this is hardly…

They're closer to the same speed now. Some of the difference could be the I/O rate the h2 server has to contend with, right?

The real way to demonstrate this would be to release a VM or container for people to test on their own server. And add a demo page of large assets, like you suggest.

Re: HTTP/2 technology demo

#62

Post by nly »

patrickmcmanus wrote: post #57
nly wrote: post #56

Earlier quoted context omitted.

...and if you enable pipelining in Firefox, it's only 20% slower than HTTP/2 (~1.6s vs ~1.3s).

but pipelines have some real poorly performing cases (head of line blocking, cancel and retry semantics, etc..) that don't apply to h2 - those gotchas aren't represented in this test.

Yup, it's true there are pathological cases.

Problems with HOL blocking can be reduced significantly with good caching though. 50 blocking requests aren't much of an issue if they're all going to return small "304 Not Modified" responses straight out of the web servers file cache.

And don't forget you can still get HOL blocking over HTTP/2... at the end of the day the browser has to start parsing HTML before it knows what else it needs to request. The only alternative is teaching your web server HTML or a set of heuristics and doing PUSH. And PUSH actually counter-acts the good in caching because when I load your index.html the web server has no idea whether I have jquery or your blogs stylesheet cached or not.

What I really want when I visit a URL is for my browser to tell the web server when I last visited, and then for the web server to give me a complete list of all dependent resources and sub-resources that have changed since that visit.... basically a set of HEAD responses that constitute a diff. My browser can then just say "hmm, ok, I needed these last time, and they've changed, so while I'm downloading index.html I'll just go ahead and request this and this and this even though I have no idea how I'm going to load them yet".

Basically, imho, all webpages should be cached as git repos ;)

Re: HTTP/2 technology demo

#63

Post by pluma »

Chrome 43 on Linux from Germany here.

HTTP/2 routinely outperforms HTTP/1.1 by several seconds for me. HTTP/1.1 being somewhat stable at 7-8 seconds and HTTP varying from 4 to 11 seconds (though generally closer to 11 seconds than to 4).

The Akamai demo works fine: https://http2.akamai.com/demo (though HTTP/2 is only ahead by 20% or so)

Re: HTTP/2 technology demo

#64

Post by sulami »

halosghost wrote: post #60
sulami wrote: post #59

Ran this a couple of times in Firefox 40/Linux x86_64, HTTP/1.1 was always faster by 10-20% (~1s vs. ~1.15s).

In my case (and I'm not sure why), HTTP/1.1 consistently got ~5s and HTTP/2 consistently got ~10s. I assume I was supposed to see the opposite result? :P

Reading the comments here, the results seem to fluctuate heavily in dimensions, winners and margins.

I guess, this test is just not an epitome of anything at all.

Re: HTTP/2 technology demo

#65

Post by patrickmcmanus »

nly wrote: post #62
patrickmcmanus wrote: post #57

Earlier quoted context omitted.

but pipelines have some real poorly performing cases (head of line blocking, cancel and retry semantics, etc..) that don't apply to h2 - those gotchas aren't represented in this test.

Yup, it's true there are pathological cases. Problems with HOL blocking can be reduced significantly with good caching though. 50 blocking requests aren't much of an issue if they're all going to return small "304 Not Modified" responses straight out of the web servers file cache. And don't forget you can still get HOL blocking over HTTP/2... at the end of the day the browser has to start parsing HTML before it knows…

h2 is better than that.. each request carries a priority, so the server can stop sending one resource and start sending another higher priority one if it becomes available. It can even do this interleaving based on actual data available to send not just the request queue - so things like CPU and IO time on one high-priority resource don't become blockers to using the bandwidth for a lower-pri resource that is ready to go.

Obviously that requires a decent server implementation that uses smallish sending chunks and doesn't over buffer.

So the browser should not reorder requests and hold some back (they all do play those games in h1) with h2 - it should just set the pri/dep flags well to give the server (which is going to do the sending) maximum information.

The real HOL problem with h2 involves TCP loss recovery. Its a fairly minor issue though in practice.

Post reply on HN