Efficient node.js IPC

526 views
Skip to first unread message

Tim Dickinson

unread,
May 12, 2014, 8:11:06 PM5/12/14
to nod...@googlegroups.com
Hey all.

I would like to know from peeps what could be the best IPC.

I have written this code to test what I might use.

Background.

I have a UDP server receiving messages at a high rate of speed. The server stores the last 1500x1000 messages in memory.
I have a web server that reads the messages and streams them out to clients.

UDP -> Memory -> WebServer -> HTTP

At the moment my server is only one process. I have bottlenecks. Im looking to setup a multi-process server.

What I'm thinking is something like:

UDP1,UDP2,UDP3 -> IPC -> WebServer1-memory/WebServer2-memory/WebServer3-memory -> HTTP

The UDP server/s receives messages. The UDP send the messages over TCP to the web server. The web server sends the messages to multiple clients over HTTP.

Im looking to scale this up over many cores.

From my test I have found that RAW TCP connection seems to be the best performer.


Any advice on this would be very cool.


SIDE NOTE:
I have thought about saving messages into a database like redis but I have found that redis is really slow compared to TCP/Memory.


Thanks

greelgorke

unread,
May 14, 2014, 3:42:58 AM5/14/14
to nod...@googlegroups.com
you could put a message queue between your udp and web servers. in this case you could scale them independently. as long as a delay between udp inbound and http outbound is acceptable, i'd go with that.

if it is ok that one udp-server and one webserver are bound together, then one could fork the other and comunicate other the built-in ipc channel, which is via unix socket. i guessthis solution would give you even faster ipc channel. but when you have to scale, then you scale both, which might be not the best thing

Peter Rust

unread,
May 15, 2014, 9:49:15 AM5/15/14
to nod...@googlegroups.com
I'm no expert, but I think greelgorke is right -- unix [domain] sockets are the most performant IPC available in node. This doesn't mean you are constrained to StdIn/StdOut -- you can create names for sockets and read/write to them from multiple processes. The names look like file names (they use the file system namespace) but they don't actually touch the disk.


-- peter rust
Reply all
Reply to author
Forward
0 new messages