seo Question posted in
Some basic information to get you started with this can be found here.

Node.js Express server: running res.render() / ejs.render() using Node.js threadpool – SEO

We have an app that uses server-side rendering for SEO purposes using EJS templating.

I am well-versed with Node.js and know that it’s probably possible to tap into the Node.js threadpool for asynchronous I/O for whatever purpose you want, whether it’s a good idea or a bad idea. Currently I am wondering if it is possible to run ejs.render() or res.render() with a thread in the threadpool instead of the main thread in Node.js?

We are doing a lot of heavy computational lifting in the render functions and we definitely want that off the main thread, otherwise we will be paying $$$ for more servers.

Tags:

3

Answers


  1. 0

    Is it just the rendering that is concerning you? There are other template engines which should produce better results; being that template rendering should be an idempotent operation, you could additionally distribute across a cluster.

    V8 will compile your code to assembly and, if your not hitting any deoptimizations or getting stalled by the garbage collector, I believe you should be in the neighborhood of your network I/O limits. I would definitely recommend you try other template engines, adding a caching HTTP reverse proxy at the front and running some benchmarks first.

    Login or Signup to reply.
  2. 0

    EJS is known to be synchronous, and that’s not going to change, so basically it’s an inefficient rendering engine for Node.js since it blocks the JS thread whenever it renders a view, which degrades your overall throughput, especially if your rendering is CPU heavy.

    You should definitely think about some other options. E.g. https://github.com/ericf/express-handlebars

    If you really have CPU-heavy computation in your webserver, then Node.js is definitely not the right tool for the job anyway. There are much better servers to handle multi-threading and parallel processing. You could just setup Node to be a controller and forward your CPU-heavy requests to a backend service/server that can do the heavy-lifting.

    It would be helpful to see what kind of computation you are doing during render to provide a better answer.

    Tapping into the thread-pool (which is handled by libuv) would probably be a bad idea, but it is possible of course.. you just need some C++ skills and the uv_queue_work() method of the libuv library to schedule stuff on a worker thread.

    Login or Signup to reply.
  3. 0

    I have experimented with building a scripting engine that is run in a forked process (Read on node’s child process module here). I find that to be an attractive proposition for implementing rendering engines. Yes there are issues of passing parameters (post/get query strings, session status, etc) but they are easy to deal with, especially if you use the fork option (as opposed to exec or spawn). There are standard messaging methods to communicate between the child and parent.

    The only overhead is the generation of the additional instance of node (the rendering engine itself). If you are doing extensive computation in the scripting engine then this constant, the one-time per rendering request overhead of forking a new process will be minor compared to the time taken to render.

    If EJS rendering blocks the main node thread, then that alone is sufficient reason NOT to use it if you are doing any significant computation during rendering.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search