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

Hi Henrik,

As I understand it, it isn't V8 that affords the asynchrony and instead
libuv.

I think we can probably learn our answer from this page (I am reading right
now): https://nikhilm.github.io/uvbook/basics.html



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


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

Aaron

I think Tim is the best to answer that question or I can write Lars Bak

(a

fellow
Danish) that made the V8 and thereby the C code

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

So, if I'm understanding you correctly, cluster won't allow us to use

multiple cores on the IBM i because IBM i jobs run as single threads.

Cluster *will* allow multiple cores to be used, but multiple cores will
also be used without the cluster npm, though only when a Node.js API

calls

upon a C API to do the threading. This is what Henrik and I aren't yet

in

agreement about.


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


On Wed, Oct 14, 2015 at 10:26 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx

wrote:

Aaron,

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).

I sent my last email before I received your response above.

So, if I'm understanding you correctly, cluster won't allow us to use
multiple cores on the IBM i because IBM i jobs run as single threads.
However, this is not such a big deal, since the node event loop hands

off

I/O blocking code to worker threads. The worker threads are executed

in C

and take advantage of IBM i's multiple cores.

I recognize your caveat that you are sharing your best understanding.

But

I want to make sure that I have the gist of what you are saying.

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 Kelly
Cookson
Sent: Wednesday, October 14, 2015 9: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

Henrik,

Out of curiosity, why is it that the cluster module can't be used to

take

advantage of multiple cores on the IBM i?

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

Henrik

Rützou
Sent: Wednesday, October 14, 2015 9:30 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

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.

--
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.