6 ms·

OK from single core $10 VPS you will be able to serve 1,080,000 unique initial loads per hour and depending on your pattern of traffic say 15,000,000 in a day

by qaq 9y ago

OK from single core $10 VPS you will be able to serve 1,080,000 unique initial loads per hour and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?

foepys 9y ago
The issue is that it could be ~14,040,000.
dustingetz 9y ago
It's a real issue, my startup's react SSR times are ~5 seconds of blocking the node thread on my $40 droplet. It's about 50% react. Our pages are way more sophisticated than your average page with like a query and a form, though. There are many ways to make faster though, one of which is to simply configure your CDN properly.
- abritinthebay 9y ago
  5 seconds per request?? What on earth? Our entire app is React+Redux based, gathers a bunch of unique user data per-request from various apis and we still get ~40-120ms response times (and that's on CDN cache misses). Hell, our Node server's connection timeout is 3 seconds and we only ever hit that due an APIs tanking or something.
- qaq 9y ago
  did you ever consider that you might not be doing something right ?
  - dustingetz 9y ago
    Not really, I'm the consultant people hire when they need to solve issues like this. There are some screenshots of what we're doing here: http://www.hyperfiddle-consulting.com/ http://www.hyperfiddle-consulting.com/ http://hyperfiddle.net/ http://hyperfiddle.net/ As I said, our app is sophisticated
    - setr 9y ago
      Why in the world would you take over scrolling like that Is this how you get your kicks?
      - dfee 9y ago
        I thought, “can’t be that bad”. The clicked and it was unusable on my phone. That is bad.
        dustingetz 9y ago
        What is the scroll bug exactly, or are you referring to the perf problems?
        dfee 9y ago
        No, I opened it on my iPhone X, and regular scrolling (moving my finger up / down the screen) doesn't move the webpage. Instead, I have to try and click the scrollbar on the right hand side (on my iPhone!) and then move the scroller in the opposite direction as I'd swipe.
        dustingetz 9y ago
        wow, thanks
        setr 9y ago
        On iphone sc chrome browser, what they've apparently done is completely reimplemented scrolling; the website has its own scrollbar, on top of which chrome renders its own, and the site seems to be scrolling in place of the browser, as the "smooth-scrolling" behavior is entirely gone, as well as other little things like scrolling past the end of the page and being bumped back up
        dustingetz 9y ago
        ah its just a flexbox css bug, thanks for the report
- batmansmk 9y ago
  50% on plain rendering is very unexpected. Complex apps tend to have bottlenecks on IO/data fetching more than just plain rendering. I would love an article detailing your experience and measurements.
  - dustingetz 9y ago
    our renders are compute heavy because it is so dynamic (most of today's apps aren't). Think of it this way. Virtual DOM is like a spreadsheet. You only want to recompute the stuff downstream of what's changed. That's basically what React's render-tree pruning is all about. But there are a couple problems. First, naive server rendered React isn't diffing anything at all, it recomputes the whole virtual dom from scratch every time. So there isn't any render-tree pruning since we're not doing a diff. That's what the walmart-labs patches help with, since obviously a lot of SSR'ed components aren't changing between SSRs, that can be reused, and we can be fast again. Second, React.js views are more than just banging html together, it also has to call a bunch of functions as part of that process. For example client side sorting, or map/reduce/filter. So if those functions are expensive, your views are slow, even if the html itself isn't all that complex. Third, since much of our "view rendering" cost is actually computation not directly related to making html, React can't reuse pieces of those computations anyway. You'd need to code your "math" in terms of React components even though there's no html associated with them. Fourth, if your dataflows are dynamic enough, like a spreadsheet, even if React actually could optimize those computations (which it cant), it wouldn't even be helpful, because while Views are trees, many computations are not. For example, in a spreadsheet: Edit cell C7, quick what is the tree of computations you can skip? The question doesn't even make sense, because spreadsheets aren't trees. Spreadsheets do complicated graph dependency tracking, with cycle analysis and all that, in order to make this fast. React doesn't do that. As an example of how dynamic Hyperfiddle is, go to http://dustingetzcom2.hyperfiddle.net/ http://dustingetzcom2.hyperfiddle.net/ and in the top toolbar click "data" and then click "dev". Dustingetzcom2 is not coded in javascript, its coded in data, and you edit the data live in the dev pane, and the right things update live as you make changes. That's why the render computation is so expensive.
    - abritinthebay 9y ago
olegkikin 9y ago
The issue is other solutions give you ~10X more page loads per unit of time at the same price.
rsynnott 9y ago
Assuming that your actual use case is rendering one small HTML table, yes. It probably isn’t, though.
- qaq 9y ago
  OK lets assume it's 30x that do you really think that 300/month for SSR would be an issue for a site serving 400 mil sessions per month?
  - lwansbrough 9y ago
    Is optimizing for cost efficiency a cardinal sin on HN now?
    - qaq 9y ago
      If you spend 20K in developer time to optimize for few hundred/month savings you are not going to be saving much (and that is not counting the cost of maintaining that extra code over time)
  - rsynnott 9y ago
    Given the latencies shown in the article, if it's 30x that it'd probably take a few hundred ms to render. I'd view that as unacceptably slow; your milage may vary. Also, I suspect 30x that is optimistic for a complex site; it is a single small table. 400m sessions a month doesn't really sound like that much...
ec109685 9y ago
Latency still matters though. A stack that can render things in 50ms likely ends up simpler than one that takes 500ms, where things like caching templates, esi, start being introduced to compensate for latency.

by qaq 9y ago

foepys 9y ago

The issue is that it could be ~14,040,000.

dustingetz 9y ago

It's a real issue, my startup's react SSR times are ~5 seconds of blocking the node thread on my $40 droplet. It's about 50% react. Our pages are way more sophisticated than your average page with like a query and a form, though. There are many ways to make faster though, one of which is to simply configure your CDN properly.

abritinthebay 9y ago
5 seconds per request?? What on earth? Our entire app is React+Redux based, gathers a bunch of unique user data per-request from various apis and we still get ~40-120ms response times (and that's on CDN cache misses). Hell, our Node server's connection timeout is 3 seconds and we only ever hit that due an APIs tanking or something.
qaq 9y ago
did you ever consider that you might not be doing something right ?
- dustingetz 9y ago
  Not really, I'm the consultant people hire when they need to solve issues like this. There are some screenshots of what we're doing here: http://www.hyperfiddle-consulting.com/ http://www.hyperfiddle-consulting.com/ http://hyperfiddle.net/ http://hyperfiddle.net/ As I said, our app is sophisticated
  - setr 9y ago
    Why in the world would you take over scrolling like that Is this how you get your kicks?
    - dfee 9y ago
      I thought, “can’t be that bad”. The clicked and it was unusable on my phone. That is bad.
      - dustingetz 9y ago
        What is the scroll bug exactly, or are you referring to the perf problems?
        dfee 9y ago
        No, I opened it on my iPhone X, and regular scrolling (moving my finger up / down the screen) doesn't move the webpage. Instead, I have to try and click the scrollbar on the right hand side (on my iPhone!) and then move the scroller in the opposite direction as I'd swipe.
        dustingetz 9y ago
        wow, thanks
        setr 9y ago
        On iphone sc chrome browser, what they've apparently done is completely reimplemented scrolling; the website has its own scrollbar, on top of which chrome renders its own, and the site seems to be scrolling in place of the browser, as the "smooth-scrolling" behavior is entirely gone, as well as other little things like scrolling past the end of the page and being bumped back up
        dustingetz 9y ago
        ah its just a flexbox css bug, thanks for the report
batmansmk 9y ago
50% on plain rendering is very unexpected. Complex apps tend to have bottlenecks on IO/data fetching more than just plain rendering. I would love an article detailing your experience and measurements.
- dustingetz 9y ago
  our renders are compute heavy because it is so dynamic (most of today's apps aren't). Think of it this way. Virtual DOM is like a spreadsheet. You only want to recompute the stuff downstream of what's changed. That's basically what React's render-tree pruning is all about. But there are a couple problems. First, naive server rendered React isn't diffing anything at all, it recomputes the whole virtual dom from scratch every time. So there isn't any render-tree pruning since we're not doing a diff. That's what the walmart-labs patches help with, since obviously a lot of SSR'ed components aren't changing between SSRs, that can be reused, and we can be fast again. Second, React.js views are more than just banging html together, it also has to call a bunch of functions as part of that process. For example client side sorting, or map/reduce/filter. So if those functions are expensive, your views are slow, even if the html itself isn't all that complex. Third, since much of our "view rendering" cost is actually computation not directly related to making html, React can't reuse pieces of those computations anyway. You'd need to code your "math" in terms of React components even though there's no html associated with them. Fourth, if your dataflows are dynamic enough, like a spreadsheet, even if React actually could optimize those computations (which it cant), it wouldn't even be helpful, because while Views are trees, many computations are not. For example, in a spreadsheet: Edit cell C7, quick what is the tree of computations you can skip? The question doesn't even make sense, because spreadsheets aren't trees. Spreadsheets do complicated graph dependency tracking, with cycle analysis and all that, in order to make this fast. React doesn't do that. As an example of how dynamic Hyperfiddle is, go to http://dustingetzcom2.hyperfiddle.net/ http://dustingetzcom2.hyperfiddle.net/ and in the top toolbar click "data" and then click "dev". Dustingetzcom2 is not coded in javascript, its coded in data, and you edit the data live in the dev pane, and the right things update live as you make changes. That's why the render computation is so expensive.
  - abritinthebay 9y ago

olegkikin 9y ago

The issue is other solutions give you ~10X more page loads per unit of time at the same price.

rsynnott 9y ago

Assuming that your actual use case is rendering one small HTML table, yes. It probably isn’t, though.

qaq 9y ago
OK lets assume it's 30x that do you really think that 300/month for SSR would be an issue for a site serving 400 mil sessions per month?
- lwansbrough 9y ago
  Is optimizing for cost efficiency a cardinal sin on HN now?
  - qaq 9y ago
    If you spend 20K in developer time to optimize for few hundred/month savings you are not going to be saving much (and that is not counting the cost of maintaining that extra code over time)
- rsynnott 9y ago
  Given the latencies shown in the article, if it's 30x that it'd probably take a few hundred ms to render. I'd view that as unacceptably slow; your milage may vary. Also, I suspect 30x that is optimistic for a complex site; it is a single small table. 400m sessions a month doesn't really sound like that much...

ec109685 9y ago

Latency still matters though. A stack that can render things in 50ms likely ends up simpler than one that takes 500ms, where things like caching templates, esi, start being introduced to compensate for latency.