Node.JS 0.3.4 out (with experimental HTTPS) | Hacker News Reader

Node.JS 0.3.4 out (with experimental HTTPS)

groups.google.com

63 pointsRauchg13 comments

I've been using node for a while now and I have to say it's a lot awesomer than it was when I first started playing with it. Or maybe I'm just better with javascript ...

Either way, I love that it continues to get better, but I wonder how long they'll be able to (need to?) keep this breakneck pace. Just a few weeks ago it would seem 0.3.2 was a beta and now this.

I'm almost having to keep an eye out more on node updates than changing requirements for my code!

You can use the stable (0.2.x) branch.

I need some of the 0.3.x features :)

You don't need to update once the features you need work for you :-)

What a coincidence, I was just on the node.js site planning to write something new with it when I saw this. I implemented a heartbeat-based web stats service but it's too resource-intensive to run affordably on Apache/MySQL. I hope to write the little script that records the heartbeats in node.js with mongodb instead.

Have you considered Redis for persistence in place of MongoDB? It's excellent for stats applications.

There are companies doing stats applications using MongoDB too. It's supposedly one of its strengths. I'll look into Redis too, though.

I've seen people using MongoDB in memory only as a cache, so that they can mapreduce it. Even without that, it's writes to disk are async so it's fast.

What's the point of map reduce if data can be held in memory ?

why do you think it's better than MongoDB for stats?

> I implemented a heartbeat-based web stats service but it's too resource-intensive to run affordably on Apache/MySQL.

I don't buy that. Maybe with the default configs, but apache+mysql are incredibly tunable.

It's being added to an existing service, so when I turn it on, it needs to be able to handle 10-20,000 concurrent visitors from the start. I tested that with two Amazon EC2 Medium instances as load balanced web servers, running Apache with only the minimum necessary modules enabled and tuned parameters, and the load (and resulting response times) was too high. More servers than that would be too expensive to support rolling out the feature to the current user base, so I need to try what I can to handle it with the resources I can afford.

If I can handle that concurrency with node.js without overloading the same number of servers, then it would become viable. With 1000+ requests per second that just need to dump some data and leave with empty responses, a non-blocking server that just queues up the database writes and gets rid of the connection fast could do that. Apache's got to load up and tear down the whole PHP environment and wait for the database query to run before it can finish with each connection.

Reply on news.ycombinator.com