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

11–20 of 72 posts

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

#11

Post by arca_vorago »

runeks wrote: post #10

I'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…

Aren't there more performant options than restful these days? Any particular reason why you didn't choose those?

Would that be a good case for websockets?

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

#12

Post by wongarsu »

I don't think that the server is in charge of priorisation here. The server can do it, but there is no reason to push this responsibility onto the server when the browser can do it much better (for example the server can't know what's in the viewport).

I expect this will be quickly sorted out by more mature HTTP/2 implementations in browsers. Downloading every image at once is obviously a bad idea, and I expect such naive behaviour will soon be replaced by decent heuristics (even just downloading eight resources at once should be better in nearly all cases)

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

#14

Post by xzyfer »

noahcollins wrote: post #13

Thanks for posting your findings - very useful data. It would be interesting to see the Webpagetest waterfalls in greater detail if you're able to share that. You planning to use your resource hints to enable server push at CDN edge?

Server push at the edge is problem atm. Current push semantics require the HTML document say which resources to push. That's an issue if you're serving assets off a CDN domain.

Asset domains make less since with h2 from a performance perspective but there are still security concerns that need to addressed.

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

#15

Post by hendry »

mkj wrote: post #5

This seems to bode badly for CDNs versus own tuned servers, unless there's a way for origin websites to provide hints on response ordering?

damn, CloudFront already doesn't expose many tunables, so yeah, this isn't going to work.

Starting to wish Appcache manifest actually was made to work and that could use used as a queue somehow to prioritise important assets on a Webpage.

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

#16

Post by joobus »

One 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.

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

#17

Post by xzyfer »

arca_vorago wrote: post #11
runeks wrote: post #10

I'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…

Aren't there more performant options than restful these days? Any particular reason why you didn't choose those? Would that be a good case for websockets?

H2's single long lived connection means it's a contender to replace websockets. As a bonus you get to use HTTP semantics.

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

#18

Post by runeks »

arca_vorago wrote: post #11
runeks wrote: post #10

I'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…

Aren't there more performant options than restful these days? Any particular reason why you didn't choose those? Would that be a good case for websockets?

There are definitely more performant options. I considered ZeroMQ for a while, and almost decided on it, but went for HTTP/REST because of the built-in error handling, and request-response style (as far as I can see, I would have to implement all of this if I chose to use ZeroMQ).

I also chose HTTP because, at the end of the day, I still get almost ~1000 payment per second after the change (on a laptop). VISA handles 200k payments/second at peak, so that's peak VISA levels on 200 MacBook Pros.

I see I might have misspoke when I said "front-end". It's really the front-end (logic part) of the backend server, which now comprises two parts: stateless logic ("front-end") and database (stateful) backend. So I haven't considered Websockets.

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

#19

Post by xzyfer »

joobus wrote: post #16

One 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.

Totally. There are a bunch of ways to address the performance issue. As I alluded to at the end of the post there serious technology considerations when preprocessing so much image data.

We're currently looking at whether we can solve use IntersectionObserver for efficient lazy loading of images before the enter the viewport.

Post reply on HN