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

Real-world HTTP/2: 400GB of images per day

99designs.com.au

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Real-world HTTP/2: 400GB of images per day

#41

Post by manigandham »

Some solutions:

- Serve less data. The best speedup is when there's no more data to download and if the throughput for clients is maxed out, then decreasing page weight helps.

- Use async bootstrap JS code to load in other scripts once images are done loading or other page load events have fired.

- Load less images in parallel, use JS to load one row of images at a time.

- Use HTTP/2 push (which CloudFlare offers) to push some of the images/assets with any other response. Push images with the original HTML and you'll start getting the images to browser before it even parses the HTML and starts any (prioritized) requests.

Re: Real-world HTTP/2: 400GB of images per day

#42

Post by brobinson »

rgbrenner wrote: post #31
xzyfer wrote: post #27

Earlier quoted context omitted.

To the best of my knowledge you are correct about how CloudFlare works. For context this data was collected over the period about a month on real production pages with significant traffic. The edges were well and truely primed.

although cloudflare doesn't manage caches on a per account basis. Each PoP has a single LRU cache that's used for all customers. In other words, even if you've primed it, your files may have been pushed out of the cache by a larger customer. In order to know this hasn't occurred, you really have to check the hit rate cloudflare is reporting (for static files that rarely change, this should be near or at 100%)... and…

>Each PoP has a single LRU cache that's used for all customers.

Is this true for all tiers of paid accounts? Can someone from CF chime in here?

Re: Real-world HTTP/2: 400GB of images per day

#45

Post by amock »

dpc_pw wrote: post #36

I did not do any real tests and I might be completely wrong etc. but it seems to me that http2 is going to perform poorly over wireless links like 3g. With http1 one had N tcp connections, and with the way tcp slowly increases the bandwidth used, and rapidly decreases it when packet is lost, even if any packet were dropped (which will happen quite a lot on 3g) other tcp streams were not delayed, or blocked, and can e…

Have you looked at QUIC? It seems like it addresses the problems with HTTP2 over TCP as well as providing some additional benefits like like speeding up the secure connection establishment.

Re: Real-world HTTP/2: 400GB of images per day

#46

Post by Lukasa »

dpc_pw wrote: post #36

I did not do any real tests and I might be completely wrong etc. but it seems to me that http2 is going to perform poorly over wireless links like 3g. With http1 one had N tcp connections, and with the way tcp slowly increases the bandwidth used, and rapidly decreases it when packet is lost, even if any packet were dropped (which will happen quite a lot on 3g) other tcp streams were not delayed, or blocked, and can e…

This is a real worry, but as with all things the actual behaviour of H2 on lossy networks is more complex than that.

TCP's congestion control algorithms don't work that well when you have many TCP streams competing for the same bandwidth. This is because while packet loss is a property of the link, not an individual TCP stream, each packet loss event necessarily only affects one TCP stream. This means the others don't get the true feedback about the lossiness of the connection. This behaviour can lead to a situation where all of your TCP streams try to over-ramp.

A single stream generally behaves better on such a link: it's getting a much more complete picture of the world.

However, your HOL blocking concern is real. This is why QUIC is being worked on. In QUIC, each HTTP request/response is streamed independently over UDP, which gets the behaviour you're talking about here, while also maintaining an overall view of packet loss for rate limiting purposes.

Re: Real-world HTTP/2: 400GB of images per day

#47

Post by foota »

xzyfer wrote: post #35
foota wrote: post #34

Earlier quoted context omitted.

I think the real solution hear is for the browser to be able to communicate some sort of priority to the server, without having to download a limited number of files at once.

Browser do currently do this. H2 has two types of prioritisations: weighted, and dependency. All browsers implement weighted resource prioritisation and weigh resources by content type. This is a hold over from what they do for HTTP/1 connections. Firefox has dependency resources prioritisation. https://bitsup.blogspot.com.au/2015/01/http2-dependency-prio... The spec purposely leave how these heuristics should work t…

Oh wow, that's cool. Do you know if servers currently support this? Would this mostly be useful on a network level or do you think it would also be useful for like trying to be more intelligent about scheduling?

Re: Real-world HTTP/2: 400GB of images per day

#48

Post by dpc_pw »

Lukasa wrote: post #46
dpc_pw wrote: post #36

I did not do any real tests and I might be completely wrong etc. but it seems to me that http2 is going to perform poorly over wireless links like 3g. With http1 one had N tcp connections, and with the way tcp slowly increases the bandwidth used, and rapidly decreases it when packet is lost, even if any packet were dropped (which will happen quite a lot on 3g) other tcp streams were not delayed, or blocked, and can e…

This is a real worry, but as with all things the actual behaviour of H2 on lossy networks is more complex than that. TCP's congestion control algorithms don't work that well when you have many TCP streams competing for the same bandwidth. This is because while packet loss is a property of the link , not an individual TCP stream, each packet loss event necessarily only affects one TCP stream. This means the others don…

Agreed about possibility of over-ramp on good links. But on wireless packets drops can be quite frequent and unrelated to reaching bandwidth limit.

Re: Real-world HTTP/2: 400GB of images per day

#49

Post by dpc_pw »

amock wrote: post #45
dpc_pw wrote: post #36

I did not do any real tests and I might be completely wrong etc. but it seems to me that http2 is going to perform poorly over wireless links like 3g. With http1 one had N tcp connections, and with the way tcp slowly increases the bandwidth used, and rapidly decreases it when packet is lost, even if any packet were dropped (which will happen quite a lot on 3g) other tcp streams were not delayed, or blocked, and can e…

Have you looked at QUIC? It seems like it addresses the problems with HTTP2 over TCP as well as providing some additional benefits like like speeding up the secure connection establishment.

Yes, I'm aware of it, though not as in-depth as I'd like to. AFAIK, it was a bit unfinished yet eg. not having any congestion control story, which is very important. But yeah... it's what what HTTP2 probably should have been in the first place.

Re: Real-world HTTP/2: 400GB of images per day

#50

Post by xzyfer »

foota wrote: post #47
xzyfer wrote: post #35

Earlier quoted context omitted.

Browser do currently do this. H2 has two types of prioritisations: weighted, and dependency. All browsers implement weighted resource prioritisation and weigh resources by content type. This is a hold over from what they do for HTTP/1 connections. Firefox has dependency resources prioritisation. https://bitsup.blogspot.com.au/2015/01/http2-dependency-prio... The spec purposely leave how these heuristics should work t…

Oh wow, that's cool. Do you know if servers currently support this? Would this mostly be useful on a network level or do you think it would also be useful for like trying to be more intelligent about scheduling?

It's hard to say for sure. Server implementations can vary wildly, make sure to test any implementation closely. I know from talking to CloudFlare that their implementation respects browser hints. Their implementation is also open source.
Post reply on HN