Live data from Hacker News

HTTP/2 technology demo

http2demo.io

21–30 of 100 posts

Re: HTTP/2 technology demo

#22
Cheaper and faster than AWS Cloudfront with free custom SSL. So what is the catch?

One issue is our data is on S3 and I believe that any outgoing S3 traffic to this CDN would be slow and cost money, but S3 to CloudFront is is likely prioritized and free.

Re: HTTP/2 technology demo

#23
post #18
post #2

Hm, HTTP/1.1 at 15.5s, HTTP/2 at 23.72s Yeah, I "can see the difference clearly", but I don't think it is the kind of difference they expected or intended. Edit: Firefox 40 on Windows 7 at work. Will try at home as well. Oddly enough, the Akamai demo someone else posted gives me 18.47s for HTTP/1.1 and 2.24s for HTTP/2.

Shit happens :) I have HTTP/1.1 at 14.54s, HTTP/2 at 2.22s .. seems more like your configuration thing?

Maybe. But the Akamai demo does show a major improvement for HTTP/2, so I think it is primarily a CDN77 thing. Maybe a bad route.

Re: HTTP/2 technology demo

#24
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…

Something is very fishy. I tested this behind the evil-proxy-of-doom on the internal network and http2 was twice as fast despite the proxy barely supporting http1...

But then real http2 against the http2 server is still 2.98 sec vs 8.65 sec.

Re: HTTP/2 technology demo

#25

It is a real world demo though? Similar to many of the other demo's of HTTP/2 (Gopher Tile, Akamai) it's written in a way that presents HTTP/1.x in the worst light and manages to screw things up even more. HTTP/1.1 is really latency prone so when you have a demo that uses lots of smalls requests that don't fill up the congestion window you run into a couple of problems. 1. The browser can only use a limited number of…

Regarding #4 isn't this a bit cheating, who doesn't use keep-alive. Also what about request pipelining? Doesn't that basically do the sane thing what http/2 is doing?

Re: HTTP/2 technology demo

#26

It is a real world demo though? Similar to many of the other demo's of HTTP/2 (Gopher Tile, Akamai) it's written in a way that presents HTTP/1.x in the worst light and manages to screw things up even more. HTTP/1.1 is really latency prone so when you have a demo that uses lots of smalls requests that don't fill up the congestion window you run into a couple of problems. 1. The browser can only use a limited number of…

This demo is representative of loading Clara.io scenes, lots of individual images and meshes:

https://clara.io/view/b43f3215-c9ef-488f-a55f-1bf2a7d74f3f

Yes, we could somehow package this up on the server and unpack it on the client, but I'd prefer HTTP/2 do that for us.

Re: HTTP/2 technology demo

#27
post #3

6.41s HTTP/1.1 vs 2.51s HTTP/2 on FF42. Very nice! (Although when HTTP2 is going the FPS drops quite a bit.) Can someone explain what exactly HTTP2 is doing differently to achieve such an improvement?

Well, they also appear to be stacking the deck a bit, by configuring HTTP/1.1 in ways that no sane person would (i.e., force-closing the connection after each resource -- HTTP/1.1 already supports re-using the existing connection for further requests, but they're explicitly disallowing that to make HTTP/2 seem better).

Re: HTTP/2 technology demo

#28
post #25

It is a real world demo though? Similar to many of the other demo's of HTTP/2 (Gopher Tile, Akamai) it's written in a way that presents HTTP/1.x in the worst light and manages to screw things up even more. HTTP/1.1 is really latency prone so when you have a demo that uses lots of smalls requests that don't fill up the congestion window you run into a couple of problems. 1. The browser can only use a limited number of…

Regarding #4 isn't this a bit cheating, who doesn't use keep-alive. Also what about request pipelining? Doesn't that basically do the sane thing what http/2 is doing?

yes #4 is totally cheating. But pipeling is very different from http/2 multiplexing. pipeling the responses has to come in order they were requested.. so it could suffer from head of line blocking. http/2 is async in that regards.
Post reply on HN