Re: Question about Node.JS and XMLSERVICE

I might be missing something...

Kevin, your separate child processes (aka IBM i jobs) are manually created
by you. My understanding is that these child processes have nothing to do
with WebSockets and instead were only necessary to get around the blocking
issues, correct?

I am *guessing* (I haven't tested this) that Node.js Websockets can operate
within a single process with, potentially, multiple threads. The state
would be held in the TCP/IP connection (see NETSTAT opt 3 for browser
clients), correct?



Aaron Bartell
litmis.com - Open Source and IBM i. No Limits.


On Wed, Sep 2, 2015 at 8:19 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Again, thanks for the information. It doesn't sound like six (6) threads in
the main JOB would support very many Web-socket connections. I seem to
recall that broadcasts require persistent connections. An Apache instance
at a client's site is running upwards to 4,000 threads to support HTTP
connections, which timeout after something like 60 seconds of inactivity. I
wonder how scalable Node might be in comparison to the Apache based server?
Is the number of Node or Sails threads configurable?





On Wed, Sep 2, 2015 at 7:02 AM, Kevin Turner <
kevin.turner@xxxxxxxxxxxxxxxxxxxx> wrote:

Yes that is right. The main node app is a web socket server, and the
child node processes are listeners that wait for entries to arrive on a
keyed data queue (one child per key). When they get data, they pass it
back to main process to broadcast to the subscribed clients.

One thing I did notice when I started looking at the stats was that my
main process was consuming a ridiculous amount of CPU. A major
worry......until I realise what it was. My app is actually a Sails.js

app

that uses Express.js under the covers. Sails also uses something called
Grunt that watches for changes to certain files and then redeploys them.
That was totally superfluous to my requirements, so I disabled Grunt and
the CPU usage returned to next to nothing. Phew! I didn't have the

time

or inclination to find out why Grunt was doing this. I suspect I needed

to

reconfigure it slightly for this platform - but I couldn't be bothered.

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