× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Aaron,

no I'm not, if node.js C modules ran multi threaded the node.js performance
would
be better on all platforms.

On Wed, Oct 14, 2015 at 5:20 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

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






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.