Down in London, GB

This is aggregate data from the GoSquared analytics network. All figures are up to the minute with historical context to show the trend.

In other words, the percentage can go lower or higher as more elements are added to the dataset.

It seems way too noisy to me. Like a data point can swing from 4.59% to 2.66% in a minute interval. That's nearly doubling, so how can you interpret either value?

The latest data point on its own can fluctuate but it's the overall trend that showcases the growth

Yeah, my thinking is that a trendline would be useful.

You're perfectly correct, and Apache has and continues to serve as one of the most successful and widely deployed web servers to date. That said, in the context of more conveniently architecting for high volumes of traffic, Apache was conceived in a time of fundamentally different problems, and in that respect it can be viewed as a more antiquated option when scoping out the landscape of appropriate web server software.

I did not intend any pejorative connotations by calling it "archaic". I just wanted to emphasise that it has been eclipsed by newer software following different design paradigms better suited to this kind of problem.

I only suggested changing tcp_tw_reuse but you are right, especially tcp_tw_recycle can have adverse effects.

According to this reference: http://www.speedguide.net/articles/linux-tweaking-121 "[tcp_tw_reuse] is generally a safer alternative to tcp_tw_recycle"

I believe the section about TCP_FIN_TIMEOUT is wrong. tcp_fin_timeout has nothing to do with the time wait state at all. TCP_TIMEWAIT_LEN is the value that holds onto the TCB

Absolutely, although Domains are a new feature in 0.8 and will need some time for maturity.

When your nodejs instances are crashing several times an hour due to facebook randomly returning html instead of json and the 3rd party library crashing as a result, who has time for maturity? =)

Wouldn't a simple uncaughtException handler be sufficient to prevent most crashes?

    process.on('uncaughtException', function (err) {
      // log it
    });

From the documentation:

"Don't use it, use domains instead. If you do use it, restart your application after every unhandled exception!"

http://nodejs.org/api/process.html#process_event_uncaughtexc...

newrelic can be used for server monitoring, and they've got a nodejs probe in development http://try.newrelic.com/nodejs.html

Downside: expensive

If it works for you for now then no real need to change it. A proper deployment tool usually makes it easier to deploy apps of different types and languages using a consistent set of tools.

What I do when working with SSH'ing to AWS instances is to give them a readable name (like nginx-1, nginx-2) tag, and then place those names as hostnames in my /etc/hosts, so I can then just run ssh nginx-1. I use a script around https://github.com/bjeanes/ghost to automate this.

The script looks nice, though if you don't want to have to use sudo to update /etc/hosts you can also just add entries in ~/.ssh/config. Downsides are that it only works for ssh-based activities.

Great pointers, setup scripts and automating project chores are essential for creating a good workflow, saving time, and saving colleagues some hair when they get started with the app.

I've tried coffeescript but it didn't catch on with me. Perhaps I didn't give it enough time, but I got the feeling that it could get quite semantically ambiguous at times whereas if you stick to JS' native C-style form, the structure of the code is imperative and easy to follow. I also felt uneasy about what code was actually executing at the other end of the transpiler.

a) You can always see the source output and it is easily readable. b) CS really doesn't do anything magic in the output.

Give it more time, the gains for CS are worth any negatives you can conjure up. do ->, classes, simple for loops, equality, etc.

The real question is what happens when you submit it ;)