Re: Apache vs Express for Node

Nice Aaron. All good stuff. It would make a great presentation at Common walking through the synchronous and asynchronous components and how they interact. Until I viewed this video I didn't have much of a grasp on what was going on as JavaScript scripts executed. Phillip did a really nice job (understandable, too)

Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
LinkedIn - www.linkedin.com/in/petehelgren
Twitter - Sys_i_Geek IBM_i_Geek

On 9/14/2016 8:00 AM, Aaron Bartell wrote:

Although Node's HTTP process is single threaded, it can be shared by

multiple forked "child" processes as reference by Aaron Bartell. Child
processes are relatively resource intensive in that they run a subset of
AIX (PASE) along with Node's JavaScript runtime.

When I was learning Node the topic of "Node is single threaded" came up a
lot, and then there were people that said it wasn't single threaded and
that confused me. So I dug deep and here's what I found...

This guy put together an ~excellent~ visualization of how Javascript works
on the client (and the same storyline holds true for the server). Highly
recommend watching this before reading my next statements:
http://latentflip.com/loupe

It's true that Node.js is single threaded. And it's also true that you can
have multiple threads in a single Node.js process (aka IBM i job). Here's
the kicker... new threads are used when I/O is done (DB, file system,
networking) because that would block (synchronous) the single threaded
Javascript event loop. Only one line of Javascript is being invoked on the
call stack at a given time in one thread. There could be other threads in
the same process that have their own event loop, and thus there would be
true parallel execution.

Javascript has additional complexities when used on the server-side because
the programmer has to be significantly more mindful of writing async code.
On the client-side it isn't as big of an issue because you have a single
user and they may not notice synchronously written code (that would block
their interaction with the page) because it happens so fast.

Before last month the IBM i DB adapter for Node.js was synchronous which
would be similar to having a single RPG-CGI job to facilitate all inbound
requests. In short, everybody waits in line for the request in front of
them to run its course. This then necessitates the multiple process (aka
IBM i job, aka Node.js clusters) approach.

Side note: Upgraded a customer from Node.js v0.12.9 to v4.4.6 on IBM i and
gained a roughly 2.5 times throughput (tested with JMeter). I only have
assumptions of why we're getting better throughput (i.e. async db adapter,
probably refined V8 Javascript runtime).


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


On Wed, Sep 14, 2016 at 12:05 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

So I can use Apache or Express for Node. Can anyone enlighten me as to
the practical differences?

I'm not aware of practical differences in regards to communications (socket
services) and the HTTP protocol given a relatively small I/O workloads.

For those who may be looking to serve thousands of concurrent connections,
the Apache based server scales in and of itself; just configure the number
of threads you want it to support. One of our clients runs 3,500+ threads
in a single instance (1 process). The Node HTTP server is a single-threaded
process. You can scale by running multiple Node instances and distributing
workloads between them via a load balancer.

Although Node's HTTP process is single threaded, it can be shared by
multiple forked "child" processes as reference by Aaron Bartell. Child
processes are relatively resource intensive in that they run a subset of
AIX (PASE) along with Node's JavaScript runtime. Node is an
application-server environment (JavaScript), whereas the Apache server is
generally used merely for communications, or reverse proxy, or encryption,
or compression.

More meaningful differences probably pertain to one's interest in using
JavaScript to process web-service requests and generate responses vs.
perhaps one's interest in using ILE languages to do the same.

Another relevant distinction, at least to me, is how web-service requests
are dispatched and routed. Under the Apache CGI design, requests may be
routed to persistent stateful jobs, or routed indiscriminately to a pool of
stateless jobs, based simply on which is available at any given moment.
Under Node, this is where a product like Express comes into play. I don't
have a high opinion of either the routing in Express, nor in Apache. I
wrote an Apache plug-in which handles application launching, request
dispatching, and routing for our application environment for much improved
scalability.
--
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.