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

Henrik,

IIS is capable of load balancing via request routing (http://www.iis.net/learn/extensions/configuring-application-request-routing-(arr)/http-load-balancing-using-application-request-routing). I would expect IIS to be as capable as Apache with respect to load balancing.

Netcraft shows Apache is still the predominant web server of the busiest sites on the Internet (53%). NGiNX comes in second at 18%, and Micrsoft IIS comes in third at 12%. Apache and IIS use appear to be on a gradual decline, while NGiNX is increasing fairly quickly. NGiNX overtook IIS just last year. (http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html)

I don't know whether or not one can combine: (a) load balancing with a reverse proxy web server, and (b) use of the cluster module in a node app.

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 11:31 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

kelly

I don't know the IIS server well, but is it ablle to load balance between let's say node.Js servers that runs on port 8787-8797 on your IBM I

On Wed, Oct 14, 2015 at 6:06 PM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

Henrik,

there is in principle nothing wrong with clustering in node.js but
you will bind yourself to a clean node.js environment.

Why would this be? Suppose I run an IIS web server on a Windows
machine. I use this IIS server as a reverse proxy to a node app that
is running on, say, port 8787 of my IBM i. Why wouldn't I be able to
use the cluster module inside the node app that is running on port 8787 of my IBM i?

You've mentioned using NGiNX as a reverse proxy. I know NGiNX was
designed to be fast. However, I've also read that NGiNX is not a good
choice on
Windows:

"Nginx on Windows is really not an option for anything you’re going to
put into production. Windows has a different way of handling event
polling and the nginx author has chosen not to support this; as such
it defaults back to using select() which isn’t overly efficient and
your performance will suffer quite quickly as a result.
NGiNX does not support, which can result in poor performance. So, if I
had to set up a reverse proxy on Windows, I would probably use IIS."
Martin Fjordvald (
https://blog.martinfjordvald.com/2011/04/optimizing-nginx-for-high-tra
ffic-loads/
)

So, if I had to set up a reverse proxy on Windows, I would probably
use IIS.

On the IBM i, I'm not sure whether NGiNX or Apache would be my choice.
I'm guessing NGiNX is faster than Apache on the IBM i. But I'm also
guessing that Apache has better tooling and more extensions to make
life easier for developers. Apache has been around longer. I might use both web servers:
Apache as a reverse proxy for most web apps, and NGiNX as a reverse
proxy for web apps that I need to scale big.

I'm always open to other points of view.

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 10:21 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

Kelly

there is in principle nothing wrong with clustering in node.js but you
will bind yourself to a clean node.js environment.

By moving load balance and reverse proxies up into NGiNX you are able
to run a mix of technologies "under the hood" such as node.js, apache
or java or even .NET

In your case you could benefit of having your .NET team and your IBM I
team working under the same platform.

For other, amoung them myself, I would need to have existing Apache
Apps running side by side with node.js.

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

Henrik,

I am not sure what you are conveying in this most recent email. Are
you in agreement with what I believe to be true?

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

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

Aaron

here is another ... (performance figures)

Node.js (stand alone) 1434s
Single threaded C 413s
Node.js + Fabric Engine 55s
Multi threaded C 53s

http://fabricengine.com/

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

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.

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

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