4 ms·

This is a copy of the Akamai's http2 demo: http://http2.akamai.com http://http2.akamai.com

by cflat 11y ago

joeblau 11y ago
My results on the Akamai page have less of a difference between the results when compared to http://www.http2demo.io http://www.http2demo.io.
- takeda 11y ago
  Akamai's test does not cheat by sending Connection: close
sajal83 11y ago
Akamai's http/1 does keep alive. This one does not.
mbq 11y ago
And Akamai's is inspired by http://http2.golang.org/gophertiles http://http2.golang.org/gophertiles (which they acknowledge).
nly 11y ago
...and if you enable pipelining in Firefox, it's only 20% slower than HTTP/2 (~1.6s vs ~1.3s).
- patrickmcmanus 11y ago
  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.
  - nly 11y ago
    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 ;)
    - patrickmcmanus 11y ago
      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.
      - nly 11y ago
        I serve Wordpress over SPDY 3.1 all the time. Not sure if that's close enough to HTTP/2 to be comparable, but I don't see how HTTP/2s capabilities will solve the following problem: And that is I still need to wait 100-200ms for PHP to spit out HTML from index.php, 100ms for the client to receive it, and another 100ms for a list of prioritised requests for dependent resources to come back. How is that not a "real HOL problem"? If you treat a request as referring to a bundle of resources rather than a single response then you can solve all that by allowing the client to send a lot more metadata about its current view of the whole package. This frees up the web server to respond with logo.png, funkystyle.css and bloated.js, or a freshness response, while we wait for PHP The only way a user-agent can solve this under HTTP/2 is to request a bunch of related resources it knows it needed the last time, at a low priority, and hope they are either needed, or unneeded but unchanged (as to not waste bandwidth). And you know, a pipelined HTTP/1.1 client can do this just fine by prefacing its primary request with a bunch of If-Modified-Since requests. And sure, you can build a webserver that can parse HTML out of PHP and do HTTP/2 PUSH, but again that's a waste of bandwidth if I have these resources cached. That's why I think it's time to move away from a simple request, response and cache model and start thinking in terms of bundle synchronisation and dependencies.

This is a copy of the Akamai's http2 demo: http://http2.akamai.com http://http2.akamai.com

by cflat 11y ago

This is a copy of the Akamai's http2 demo: http://http2.akamai.com http://http2.akamai.com

My results on the Akamai page have less of a difference between the results when compared to http://www.http2demo.io http://www.http2demo.io.

takeda 11y ago
Akamai's test does not cheat by sending Connection: close

sajal83 11y ago

Akamai's http/1 does keep alive. This one does not.

mbq 11y ago

And Akamai's is inspired by http://http2.golang.org/gophertiles http://http2.golang.org/gophertiles (which they acknowledge).

nly 11y ago

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

patrickmcmanus 11y ago
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.
- nly 11y ago
  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 ;)
  - patrickmcmanus 11y ago
    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.
    - nly 11y ago
      I serve Wordpress over SPDY 3.1 all the time. Not sure if that's close enough to HTTP/2 to be comparable, but I don't see how HTTP/2s capabilities will solve the following problem: And that is I still need to wait 100-200ms for PHP to spit out HTML from index.php, 100ms for the client to receive it, and another 100ms for a list of prioritised requests for dependent resources to come back. How is that not a "real HOL problem"? If you treat a request as referring to a bundle of resources rather than a single response then you can solve all that by allowing the client to send a lot more metadata about its current view of the whole package. This frees up the web server to respond with logo.png, funkystyle.css and bloated.js, or a freshness response, while we wait for PHP The only way a user-agent can solve this under HTTP/2 is to request a bunch of related resources it knows it needed the last time, at a low priority, and hope they are either needed, or unneeded but unchanged (as to not waste bandwidth). And you know, a pipelined HTTP/1.1 client can do this just fine by prefacing its primary request with a bunch of If-Modified-Since requests. And sure, you can build a webserver that can parse HTML out of PHP and do HTTP/2 PUSH, but again that's a waste of bandwidth if I have these resources cached. That's why I think it's time to move away from a simple request, response and cache model and start thinking in terms of bundle synchronisation and dependencies.