And still no OpenSSL 1.0.2 nor ALPN on most distros such as Debian Jessie... kinda sucks
Real-world HTTP/2: 400GB of images per day
61–70 of 72 posts
Re: Real-world HTTP/2: 400GB of images per day
#62Hey all, I'm the author of that blog post. I'll be floating around for a while, happy to answer any questions.
Well done, a great combination of clear graphs + theories.
Re: Real-world HTTP/2: 400GB of images per day
#63we also did a far less sophisticated HTTP/2 reality check: https://blog.fortrabbit.com/http2-reality-check
about the same result: real world performance boost was not soooo big.
Re: Real-world HTTP/2: 400GB of images per day
#64I 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…
> 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
Multiple HTTP connections work better for exactly this reason, because they are 'stealing' bandwidth from streaming video by 'not playing fair'. For example, 6 connections ramping back up bandwidth at 6x the rate of a single connection or sometimes only scaling back on 1/6th of the streams at once.
...which is fine because multiple parallel HTTP connections is usually a browser doing so for short-lived data transfers for active users and it is not the bulk of the data on the network.
Re: Real-world HTTP/2: 400GB of images per day
#65I 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…
I worry about TCP window scaling (and full TCP windows) when only using one TCP connection. There is a good reason download managers use multiple connections to download one file, because depending on the latency the maximum transfer rate is capped because only so many TCP packets can be in flight simultaneously. I wonder if nobody ever thought about that... HTTP1/x solved that (more by chance) with multiple connecti…
Has anybody ever used this for denial of service? Make a large request so the TCP window scales up then just stop sending ACKs. All that data has to remain in the server's memory for retransmit. Even with a really short timeout before connections are dropped you could probably tie up a lot of server memory.
Re: Real-world HTTP/2: 400GB of images per day
#66Some 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…
Wouldn't the standard solution of lazy loading images (and prioritizing critical css) help. Since they are now trying to load everything on a big page, they should only be trying to load everything above the fold.
Yes, the basic approach is the same. There's limited bandwidth and they have too many image assets going through the pipe at the same time. They can easily control this by just loading a few at a time, whether that's the first page or row or whatever (probably based on testing to see what "feels" the fastest).
It's a tried and tested approach and much better than just sending everything in the HTML in a single blast. There are hundreds of image-based sites out there, they all do this as an optimization.
Re: Real-world HTTP/2: 400GB of images per day
#67I'm really looking forward to see how much HTTP/2 will increase performance for my Bitcoin payment channel server: https://github.com/runeksvendsen/restful-payment-channel-ser... Just now I finished separating the front-end and back-end - by a RESTful protocol - and this roughly halved performance compared to using a native library (from ~2000 payments/second on my laptop to ~1000). I expect HTTP/2 to make a greater…
Useful related project: http://www.grpc.io/ is an excellent layer on top of HTTP2 for comms between backend services. It's from Google, and used by Docker and Square among others. It even comes with a rest-focused gateway https://github.com/grpc-ecosystem/grpc-gateway
Thank you for the suggestion. What do you find excellent about this? What would I get in exchange for the added complexity? I must admit that I like the notion of "raw" HTTP, particularly because the server in question will be used primarily by other web services not written by me (it's basically a payment gateway), and everyone and their girlfriend knows HTTP.
I've worked once before with Protocol Buffers, and I can't say I enjoyed it. It ended up being a layer in the middle between the data and my parser, not really serving a purpose, since my parser (written in Haskell) is more strict that the Protocol Buffers specification allows. After that I see little value in Protocol Buffers over Haskell types which are (de)serialized to/from binary data. I don't find Protocol Buffers nearly verbose enough to define a protocol, so it becomes reduced to defining data types/structures, which other tools handle much better, in my opinion.
Re: Real-world HTTP/2: 400GB of images per day
#68One way to "solve" the time to visual completion would be to make all the images, but especially the larger images, progressive scan. For very large images, the difference in visual quality between 50% downloaded and 100% downloaded on most devices isn't noticeable, so the page would appear complete in half the time.
OTOH, progressive JPEGs tend to require much more memory to decode. I do not have specific numbers to cite. Only going off of anecdotal usage of image programs over the years (e.g., Java photo uploaders that choked on progressive JPEGs).
Re: Real-world HTTP/2: 400GB of images per day
#69And still no OpenSSL 1.0.2 nor ALPN on most distros such as Debian Jessie... kinda sucks
It’s available in jessie-backports since 2016-07-02, see https://packages.debian.org/jessie-backports/libssl-dev
Given that jessie is stable, OpenSSL will not be updated to a newer version, only security updates will be made available.
What I’m trying to say: you’re never going to get it on jessie, unless you enable backports, at which point you’ll have it readily available.
Hope that helps
Re: Real-world HTTP/2: 400GB of images per day
#70Founder of NuevoCloud here. If I read this right, you guys used Cloudflare for http 2. So let me ask you this, when you did your comparison, were all of the images cached (ie: x-cache: hit) at the edge? The reason I ask is because cloudflare, last I checked, still hasn't implemented http2's client portion. So when a file is not cached, it does this: client edge node origin server. Http2 is only used for the short hop…
So does it matter for Cloudflare or affects my site's performance if I use http2 in the backend while behind Cloudflare?
you're not using http2 then, since it would never upgrade the connection to http2. So the connections to your backend are all http 1.1.