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



Nathan,



first of all, HTTP doesn’t maintain open connections in a session like
fashion, it opens a connection when a request comes, processes it and close
the connection.



In general, if we talk about RPG/CGI one QZSRCGI job may serve hundreds of
“active concurrent” users in a stateless environment and so can node.js.



“stateless” is different than “stateful” like 5250 sessions but in terms of
server resources that are no difference. 10,000 5250 users may have 10,000
jobs but most of the time their jobs are idle waiting for I/O that doesn’t
require server resources.



If all 10,000 5250 users press enter at the same time, you would see very
long response times because all their jobs would become active at the same
time but in the real world most jobs do nothing.



Do the math, if every 5250 requests took 1 sec of server resources the last
5250 user would have to wait approx. 3 hours to get an answer.



It is correct that node.js runs single treaded but here kick ASYNC/AWAIT in
because many of the asynchrony modules is able to run in other treads while
the main tread in node.js continues to process other requests.



In other words, when you fire a SQL statement against DB2 this runs in
another job (and thereby uses other free resources on the system) while
node.js continues to process other pending requests.



In order to get the maximum out of node you are also able to cluster the
one tread into a number of treads running in a single instance of node.js
and thereby spread the processes over a given number of cores in your
system. This will scale the performance of nodes to a (maximum of number of
cores * single tread performance) while the system isn’t brought down
because each node.js tread still will compete with other processes on the
system for core resources.



I have made an example that shown how node.js can take full advantage of
all available cores and resources on my I7 4 core/8 logical core 4,5Ghz
machine. It comes with a little **warning** because I had to install water
cooling to run the test with a reasonable CPU package temperature.



http://powerext.com/nodeCluster.PNG

On Sun, Mar 18, 2018 at 5:32 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Kelly,

Your assertion about Node.js "scalability" merits some clarification. That
assertion is valid in a couple of contexts. But not in others. The Node.js
event loop enables a single thread to manage thousands of socket
connections. If those connections are not doing much work, then that is a
specific case where the scalability claim is valid. The programmers who
wrote Node.js contrast the way that Node.js handles sockets with other HTTP
servers, which instantiate one thread for each socket connection, which is
a comparatively high resource utilization per socket.

The other context is when people talk about deploying Node applications to
a cloud hosting company that offers "elastic" scalability, which
essentially means deploying multiple instances of an application across a
server farm and using load-balancers to dispatch requests to a pool of
active Node.js instances. The problem with that type of "scalability" is
the cost.

Contrast that with the idea of deploying a complex ERP-class system on IBM
i. By ERP-class system, I mean one that might have a thousand database
tables, thousands of interactive applications and reports, batch processes,
and other types of workloads. Then asking IBM i to scale that "system" to
thousands or tens of thousands of concurrent users.

I hope that you can appreciate the distinction in how the term
"scalability" is used in the sense of a traditional ERP-class system. Under
IBM i, each user may be connected to and running 1-2 interactive sessions
(each session manages individual user state), and the platform may be
supporting tens of thousands of concurrently active Jobs. The platform just
handles it. Other platforms can't.

Back to talking about Node.js. It's well known that the Node.js event loop
runs in a single thread. Would that thread handle thousands of interactive
applications and reports (which is consistent with ERP-class systems), and
support thousands of concurrent users? No Way! It wouldn't even handle the
JavaScript logic required to "route" the requests for the appropriate users
to the appropriate applications; let along manage the "state" of individual
user sessions; let alone handle the callbacks that generate client
responses.

What type of "scalability" are you looking for?









On Sat, Mar 17, 2018 at 11:11 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

On the comparison of adopting Node and Java...

My shop refused to adopt Java on the IBM i because: (1) we were already
using .NET, and (2) database drivers and stored procedures were
sufficient
for the few times we needed to make .NET interact with DB2 and COBOL.

Node is different for our shop for a variety of reasons.

* Using Node would let our .NET developers stop using ADO.NET to
interact with the IBM i. Getting rid of dependency on ADO.NET would let
them move to .NET Core.

* Node uses one of the de facto standard languages of the
Internet:
JavaScript. People need to get over bad impressions they may have formed
in
olden days. JavaScript (actually ECMAScript now) has matured quite a bit
as
a language. And TypeScript offers enhancements if you want/need them. I
am
NOT saying JavaScript is the best language ever. I AM saying we already
have people in our shop who have coded JavaScript for years.

* Node has proven scalability. It is used by businesses that need
to handle very high volumes of concurrent requests as fast as possible
while keep CPU *relatively* low. Businesses like Walmart, PayPal, eBay,
LinkedIn, Netflix, Dow Jones, and others use Node because it helps them
scale well. Our company has reasons for wanting the ability to scale very
big, too. I am NOT saying other technologies don't scale (they do). I AM
saying a lot of big businesses are choosing Node as a technology to help
them scale very big-and Node has proven successful for them. We are
leaning
towards doing the same.
I don't know if I see Node replacing ILE languages in our shop. I tend to
think of Node as a niche technology. Use it when you need to process high
volumes of concurrent requests really fast while keeping CPU relatively
low. I'm not under the impression that Node/JS was intended to be a
general
purpose programming platform like .NET or Java or CL/RPG/COBOL/C. I'm not
sure why I would use Node for a batch program that runs over a large
number
of DB2 records to spit out a report. I'll keep an open mind. But someone
would have to persuade me.

Thanks,

Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<http://www.dotfoods.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: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.





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.