
An Easy Way to Build Scalable Network Programs - tbassetto
http://blog.nodejs.org/2011/10/04/an-easy-way-to-build-scalable-network-programs/
======
fleitz
I'm completely unsure what quality of javascript makes it suitable for writing
high performance systems.

Is it single threading? Is it the weird typeof crap you have to do to check if
a variable is defined? Is it the lack of integers? Is it the prototyping
system?

Node.js to me looks like a slightly better syntax than the horribly ugly C#
async calls. (Not the new async/wait system). Javascript completely pales in
comparison to F# or Haskell in terms of readability of async code.

If you prefer non-functional languages it would seem that Go would be a much
better place to start for performance than Javascript. Or clojure or scala.

Sure node.js outperforms rails, but rails isn't designed around being the
fastest webserver ever.

------
awj
...it's not the recent blog posts that are the problem, those are a response
to hype huffers in the community spouting scalability nonsense. Having vague
wording in the front matter for the project's main page doesn't help.

Many of the people currently "bashing" node are more or less aware of its
capabilities. They aren't mad at the technology itself, just that it's being
sold as much more than it is.

~~~
baudehlo
The only confusion over the wording on the front page seems to be over:
"Almost no function in Node directly performs I/O, so the process never
blocks". Which can be correctly read as: "Almost no function in Node directly
performs I/O, so the process never blocks on I/O". But my English teachers
would have told me that's too much repetition and not necessary.

~~~
awj
If your goal is to appeal to "less-than-expert" programmers, this is exactly
the kind of point where you want to be crystal clear. Blocking on CPU is the
kryptonite of evented servers. If someone is new to them you probably cannot
reiterate that point often enough.

~~~
baudehlo
On the front page? Really? I'd expect that on a more detailed tutorial, but to
get people interested in a technology, I completely disagree.

You don't see Apple plastering "ONLY AVAILABLE IN THE USA" on their pages
about iCloud music storage for exactly this reason - you want to get people to
say "Hmm, that sounds cool" before introducing them to the caveats.

------
ismarc
I've had to write a few network based applications that each had their own
unique performance requirements. Node.js would not have been a fit for any of
them. I'd really like to give it a go, but it seems that every scenario where
it would be useful is better served by a more specific environment. Granted,
I'm pretty lousy at javascript, so getting to use javascript on the server
doesn't count, what is Node.js' ideally suited for?

~~~
kylemathews
Your comment would be a lot more interesting if you add what those network-
based applications are that you think Node.js wouldn't be a good fit for.

~~~
ismarc
Well, my comment got eaten, so here's the horribly summarized variant.

The captive portal, DHCP, DNS, firewall/access management, VLAN tag/trunk
management, route management, VPN tunnel management, SNMP Poller, SNMP server,
network device controller services running on the internet access gateway for
sports stadiums on commodity hardware running Linux. Or those same services
running on a resource constrained system with significantly lower traffic.

This is obviously a scenario where Node.js is infeasible (web based portions
had to have C bindings for anything outside of presentation layer and all
parts of the systems required significant profiling and optimizations to meet
speed and resource usage requirements). However, I've had several applications
recently where Node.js could have been a possibility, but the documentation
and overviews for it are either so beginner that you can't determine what it's
capable of or is exploring areas where there isn't precedent for what it can
do. I couldn't find a straightforward list of supported features and the ideal
use case for it.

After expecting a more detailed article covering ideal usage of Node.js, and
that not being it, I figure I would finally break down and ask "What is
Node.js' ideal usage? Under what scenario is it an ideal tool?" It's not a
knock against Node.js at all, maybe a slight one against the documentation,
but not the technology or its use.

~~~
baudehlo
And yet you describe something which sounds ideally suited to Node (or any
evented system) and call it infeasible. Node actually has pretty nice bindings
to C (well, really C++), and I see nothing in your post that it would be
incapable of.

If it was because you don't know (and didn't want to learn) Javascript I could
understand, but in terms of your comment above it seems like you just didn't
look hard enough.

~~~
catch23
not sure why you're being downvoted here, but I do agree on the c++ binding
infrastructure. I think the things he listed are quite possible in node -- I
can't see any of those things he listed that might be cpu bound.

A fairly popular small DNS system was written in node for the purposes of
development. Anyone who uses "pow" knows what I'm talking about:
<http://pow.cx>

------
sausagefeet
Scalable web apps, maybe, but "network programs", I disagree. Just spawning a
bunch of Node instances is insufficient to really scale in many network apps,
you also need a good way to communicate between them. Preferably one that
hides the fact that you are communicating between separate machines. For the
most part, web apps can get by with pushing this to the DB but I think it's a
bit much to say this is acceptable for all network programs.

~~~
CyruzDraxs
<https://github.com/hookio/hook.io>

Transparent enough?

~~~
sausagefeet
Not quite what I had in mind, but this is probably sufficient enough for me to
eat my words.

------
kqueue
No that's not the proper way of doing it. You create worker threads in
separate process that receive data from node.js, encodes them and send them
back. you don't fork on every request.

~~~
mjijackson
He's not suggesting forking. He's suggesting spinning up a new process
entirely (ffmpeg in this case).

~~~
wmf
fork+exec is even more expensive than fork. (Although in the case of video
encoding the overhead is negligible. Problems with Node.js are more likely to
be seen when an event sometime takes 100-1000 ms; it's slow enough to hurt
response times of other requests but maybe not worth farming out to another
process.)

------
maratd
_In coming releases we’ll make it even easier: just pass --balance on the
command line and Node will manage the cluster of processes._

Internet trolls _do_ improve software!

------
CPlatypus
I'm going to repeat what I said on Twitter when this first came up - dozba's
computationally-intensive-task example doesn't really illustrate the problem.
Even if the computation is buried somewhere in a library, you can more or less
predict when it's going to happen and make sure it happens in a separate
thread/process. The real hurt comes when your single-threaded server takes a
page fault. That's nowhere near so predictable or easily solved, and it still
results in your entire application stalling. Requests on other connections,
which never needed to get anywhere near the page that caused the fault and
which could have continued in a better design, will get caught in the stall.
That's just as true and just as lame as it was almost a decade when I (e.g.
<http://pl.atyp.us/wordpress/?page_id=1277>) and plenty of others were writing
about exactly these issues. Single-threaded servers are only appropriate for
workloads where requests are trivially partitionable. In other cases you can
still use events and asynchrony but you should do it in a framework that is
inherently multi-threaded to take advantage of multiple processors/cores.

~~~
baudehlo
It's true, a seg/page/fault would take down the whole server, and any requests
executing on that process would die too. However in fairness, this is one of
the advantages of using a dynamic language, rather than one where you're
dealing with memory allocation all the time.

~~~
cdavid
I think you are confused about what a page fault is: that's what happens when
the memory manager of your OS needs to load a page from the disk ("swap").
Dynamic language does not help you at all for that. It does not help you with
segfault either BTW, because typing does not have much to do with memory
management. Many statically typed languages cannot have segfaults either, from
java to haskell.

