With node express on IBM iSeries, should we use worker threads or a cluster?

Question

I've learned about node express and clusters and have been able to successfully implement it on a Windows os. The concept of the cpu cores on Windows is simple to grasp because I understand the os. We plan to test web service on the iSeries as well that will get a lot of concurrent volume. When I search for information on running nodejs in a cluster on iSeries, I'm lead to this article referring to "worker threads".

https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/blog-entry1/2020/04/02/optimizing-your-workload-using-worker-threads-in-ibm-sdk-for-nodejs-zos-v12

That leads me to the question "With node express on IBM iSeries, should we use worker threads or a cluster?"

Answer 1

note that that particular article is talking about node on a z/OS mainframe, not an IBM i (aka iSeries) midrange system.

Having said that, nodejs on Z/OS or IBM i isn't really any different than nodejs on Windows / Linux.

Take a look at this article about Single thread vs child process vs worker threads vs cluster in nodejs

Conclusion
Even though Node js provides great support for multi-threading, that doesn't necessarily mean we should always make our web applications multi-threaded. Node js is built in such a way that the default single-threaded behavior is preferred over the multi-threaded behaviour for web-servers because web-servers tend to be IO-bound and nodejs is great for handling asynchronous IO operations with minimal system resources and Nodejs is famous for this feature. The extra overhead and complexity of another thread or process makes it really difficult for a programmer to work with simple IO tasks. But there are some cases where a web server does CPU bound operations and in such cases, it is really easy to spin up a worker thread or child process and delegate that task. So, our design architecture really boils down to our application's need and requirements and we should make decisions based on that.

Given that IBM i is custom made for DB operations, nodejs' built in support of non-blocking I/O is perfect. If your getting more requests than can be handled by a single instance, by all means set up a cluster.

If you happen to be doing CPU intensive work in nodejs, then consider a child or worker process.

The key thing with IBM i (or z/OS for that matter) is those system tend to do a lot more at once compare to a "single application" Window/Linux system. You might have 64 cores or more in a given IBM i system (or logical partition) but I'd highly recommend not trying to use all of them for nodejs.

The other key thing about the IBM i is it has a whole other level of work management compared to simple Windows/Linux systems. This is what gives it the ability to do so many different things at once.

Work in an IBM i is done inside a single or multi-threaded job (basically a process). But those jobs run in a subsystem which has specific memory pools assigned and there's a defined limit to how many threads can be active at once in that subsystem/memory pool.

So even if you told node to use a 4 worker cluster, it might not actually do so depending on where your job is running.

You'll want to work with your admin's to determine where to run your nodejs application or even if it makes sense to run your nodejs jobs in their own subsystem/memory pools.