Re: Apache vs Express for Node

Excellent talk on JavaScript and the event loop. Thanks for sharing!

Todd


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Aaron Bartell
Sent: Wednesday, September 14, 2016 9:00 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Apache vs Express for Node

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.

For More Than 85 Years—Delivering Solutions That Exceed Expectations.

This communication and any transmitted documents are intended to be confidential. If there is a problem with this transmission, please contact the sender. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.