3 ms·

> SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.ren

> SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes. Let’s say that it takes you 500ms to SSR your page, that means you can at most do at most 2 requests per second. BIG CONSIDERATION If your `renderToString` is taking 500ms you should really consider using `renderToNodeStream` [1]. It will significantly reduce TTFB and runs asynchronously, letting your Node.js server handle more incoming requests. This [2] blog post goes into more detail. Also, if you don't want to use streams, Rapscallion [3] provides an asynchronous alternative to `renderToString`. [1] https://reactjs.org/docs/react-dom-server.html#rendertonodestream https://reactjs.org/docs/react-dom-server.html#rendertonodes... [2] https://zeit.co/blog/streaming-server-rendering-at-spectrum https://zeit.co/blog/streaming-server-rendering-at-spectrum [3] https://github.com/FormidableLabs/rapscallion https://github.com/FormidableLabs/rapscallion

pjc50 9y ago
> `renderToString` is taking 500ms What baffles me is that this is a long time. In that time, you've got about a billion CPU instruction executions. If you include GPUs, they can render multiple frames of complex scenes to million+ pixel buffers in that time. And people are having trouble rendering a string?
- tetha 9y ago
  Hm, I'd guess, it's latency to backend servers. Cores are plenty fast for just about every language. If you have a good network between systems, each request of any form to a backend service will introduce at least 0.5 ms of response time due to datacenter RTA, so once you hit 250 queries, that's that. And 250 queries are just one n+1 problem somewhere.
  - syrrim 9y ago
    The OP says the call is CPU bounded, which suggests that even if time is spent on the network, it is a minority of the total time.
- dpisk 9y ago
  This reminds me of an article I read a while back: https://hackernoon.com/server-side-rendering-shootout-with-marko-preact-rax-react-and-vue-25e1ae17800f https://hackernoon.com/server-side-rendering-shootout-with-m... Not sure if the benchmarks still hold now that React 16 is out, but there's definitely overhead in the general approach. > HTTP can only send strings/bytes, so it makes sense to start there and skip the overhead of building up a virtual DOM representation first. There’s a reason string based templating languages are so much faster than our modern frameworks using a virtual DOM implementation.
tetha 9y ago
Ah. I was wondering about that. Running multiple nodejs instances won't fix the impact of long-running synchronous methods in the event loop on other requests processed in the same instance. It'll just reduce impact, because you reduce the relative percentage of other requests being held hostage by a bad request. Unless you can use your loadbalancing to split requests with a risk of long-running synchronously tasks away from instances doing fast work. We're doing something like this - we got some really ugly legacy code around, which tends to abuse and overuse the application servers JDBC pool regardless of how we tune it. This causes every other request on that instance to crash and burn. This becomes even more fun if a customer retries the same request 20x and the load-balancer does round-robin. So we route the bad requests to a single martyr instance and everything works fine again except for this broken old code.

pjc50 9y ago

> `renderToString` is taking 500ms What baffles me is that this is a long time. In that time, you've got about a billion CPU instruction executions. If you include GPUs, they can render multiple frames of complex scenes to million+ pixel buffers in that time. And people are having trouble rendering a string?

tetha 9y ago
Hm, I'd guess, it's latency to backend servers. Cores are plenty fast for just about every language. If you have a good network between systems, each request of any form to a backend service will introduce at least 0.5 ms of response time due to datacenter RTA, so once you hit 250 queries, that's that. And 250 queries are just one n+1 problem somewhere.
- syrrim 9y ago
  The OP says the call is CPU bounded, which suggests that even if time is spent on the network, it is a minority of the total time.
dpisk 9y ago
This reminds me of an article I read a while back: https://hackernoon.com/server-side-rendering-shootout-with-marko-preact-rax-react-and-vue-25e1ae17800f https://hackernoon.com/server-side-rendering-shootout-with-m... Not sure if the benchmarks still hold now that React 16 is out, but there's definitely overhead in the general approach. > HTTP can only send strings/bytes, so it makes sense to start there and skip the overhead of building up a virtual DOM representation first. There’s a reason string based templating languages are so much faster than our modern frameworks using a virtual DOM implementation.

tetha 9y ago

Ah. I was wondering about that. Running multiple nodejs instances won't fix the impact of long-running synchronous methods in the event loop on other requests processed in the same instance. It'll just reduce impact, because you reduce the relative percentage of other requests being held hostage by a bad request. Unless you can use your loadbalancing to split requests with a risk of long-running synchronously tasks away from instances doing fast work. We're doing something like this - we got some really ugly legacy code around, which tends to abuse and overuse the application servers JDBC pool regardless of how we tune it. This causes every other request on that instance to crash and burn. This becomes even more fun if a customer retries the same request 20x and the load-balancer does round-robin. So we route the bad requests to a single martyr instance and everything works fine again except for this broken old code.