Re: Hosting a Large Number of Node Apps on the IBM i

Here's the kicker:

"With a little work, the previous code can be modified to utilize all of
the available cores on a machine. In the following example, the HTTP server
is refactored using the cluster module. cluster allows you to easily create
a network of processes which can share ports. In this example, a separate
process is spawned for each system core, as defined by the numCPUs
variable. Each of the child processes then implements the HTTP server, by
listening on the shared port."

He's talking about deliberate delegation of IBM i jobs (aka processes) so
multiple Javascript statements can be run in true parallel, which is not
possible with a single process. But this doesn't address the C threads
where Node.js APIs deliberately offload known I/O blocking to C threads.
When Node.js does that offloading there is in fact multiple cores being
used that originated from a single Node.js process (again, as I understand
it).

Thoughts?

Aaron Bartell
litmis.com - Services for open source on IBM i


On Wed, Oct 14, 2015 at 9:29 AM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Aaron

here is a link ...

http://cjihrig.com/blog/scaling-node-js-applications/



On Wed, Oct 14, 2015 at 4:23 PM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

it cannot use several cores at the same time so one node.js instance

is

limited to what processing power one core is able to deliever.

Are you sure this is correct and do you have a source for your

information

that we can review? Yes, Node.js runs as a single thread, but the
underlying C architecture of Node.js uses threads for blocking I/O

calls

(i.e. file system, networking, etc). So that means, as I understand

it,

that a single Node.js server could make use of many cores because of

the

underlying C threads.

Aaron Bartell
litmis.com - Services for open source on IBM i


On Wed, Oct 14, 2015 at 9:15 AM, Henrik Rützou <hr@xxxxxxxxxxxx>

wrote:

Tim

I was not saying that a single node.js instance was glued to a

specific

core
but it cannot use several cores at the same time so one node.js

instance

is

limited to what processing power one core is able to deliever.

This is not IBM Power specific, it is the same on all hw platforms.

On Wed, Oct 14, 2015 at 3:40 PM, Kelly Cookson <

KCookson@xxxxxxxxxxxx>

wrote:

Nathan,

Kelly is asking about a mix of both types of routing - External

routing

within a reverse-proxy / load-balancer as well as internal

routing

within Node's own HTTP service.

That's correct. I think my concerns have pretty well addressed in

people's

responses. I probably want to use a combination of strategies for

setting

up routes. For example:

* use a web server as a reverse proxy that routes to node apps

running

on

their own ports,

* use something like vhost or http-node-proxy within a node app

that

routes to other node apps running on their own ports,

* use something like the ExpressJS router within a node app that

routes

to

modules or sub-apps that run within the same port.

* use something like the ExpressJS router within a node app that

routes

to

different pages of the app.

I don't need to worry so much about the number of ports used by

node

apps.

I didn't hear that any of the routing strategies above would be

better

or

worse when it comes to setting up a production environment for

fail-over

and load balancing--especially if I use a web server as a reverse

proxy.

And I didn't hear that any of the routing strategies above would be

better

or worse for scaling up node apps (e.g., clustering).

Thanks,

Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of

Nathan

Andelin
Sent: Wednesday, October 14, 2015 7:46 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Hosting a Large Number of Node Apps on the

IBM

i

I am sure Kelly is talking about the top level routing to the app

and

how to handle that as opposed to the question of internal routing

to

"screens"

within the app.

Kelly is asking about a mix of both types of routing - External

routing

within a reverse-proxy / load-balancer as well as internal routing

within

Node's own HTTP service.

How would one configure both so that a broadly-scoped system

performs

well, scales well, you don't introduce too many HTTP restarts?
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)

mailing

list To post a message email: WEB400@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.