Re: [EXTERNAL] Re: Express, React, Node.JS

Nathan,

please don't refer to async/await as a specific node.js functionallity, it
is a part af ES( the ECMA standard of javascript) and is controlled
nativly by the javascript engine in node.js the same as in Chrome, the V8.

In general any muktitask function has an performance penalty since
the processor has to process instruction that controls either the async
function or a jobpool where each job either transfer the processing to
the pending other jobs by going into a long wait or reaching the treshold
time value.

We have all seen especially some java job taking all the resource out of an
IBM i and that is because that a java job easely will run until the treshold
is reached and that value (2 sec for interactive jobs and 5 sec for batch)
is a long time for one job to own even multiple treads (as java may do) in
a one core machine completely before the OS force it into wait.

Any VM is greedy from a OS multitask job delgation point of view because
functions as async/await will prevent the VM from going into what the OS
sees as a long wait.

There s many ways to try to cheat the OS from resources, Apache CGI
has one job QZSTHTTP that delegates any request to one of 40 QZSRCGI
jobs whitch means that if you have 40 active and waiting for CPU 5250
native
jobs apache is bad competitor since one apache instance controls 50 %
of the job waiting in the OS multitask pool. You can actually do the same
in node.js with the cluster module.

So it is actually a question of the matrix you build and how that controls
the "waits" and the queue and that is however you do it complicated even
in a bare native ile environment where you somtimes try to control the
systems
jobmatrix in vaious ways such as number of batchjob Qbatch can start
and process the same time, dedicated pools in wrksyssts, job priorities etc.

And some times you can end up with a so complex configuration that the
different systems actually works against each other bacuase there always
will be an overhead in any form of multitasking.


On Thu, Mar 22, 2018 at 12:15 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

On Wed, Mar 21, 2018 at 4:31 PM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

Hi Nathan,

I'm having a hard time reconciling two claims: (a) Node actually performs
less well than synchronous programming technologies, and (b) businesses
that do high volumes of web transactions say Node allowed them to process
more transactions more quickly while reducing the number of servers they
needed. These two things are causing a lot of cognitive dissonance in me.

I understand where you're coming from. You've heard big picture claims
about Node's efficiency and performance. I don't doubt the truth of them.

Then I offer a micro perspective picture into Node's architecture that
deals only with the performance impact of Node's event loop on Javascript
functions that implement async-await keywords. And that picture is
supported by benchmarks too.

What can we learn from both perspectives? I would suggest that Node.js is
really efficient at certain things, but can become really bogged down by
others. That it behooves application architects and engineers to know what
(and what not) to use Node.js for.
--
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.