Node.js in Production

Node.js inProduction

-

|

Seattle Node.js

May 8th, 2013

Ryan Roemer @ryan_roemer

OverviewProduction!

Well, what our production looks like.

Five Node.js-related things we'velearned.

Some additional resources.

What is"Production"?

Curiosity Media

Brought to youby...

A team of three engineers

Who are full-time developers

Running everything in the cloud

With minimal time available for ops

SpanishDict.com

Demo

A Spanish-EnglishDictionary

is the world’slargest Spanish-English dictionary,translation, and language learningwebsite. We develop and providereliable, accurate, easy-to-useresources for learning Spanish.

SpanishDict.com

Our visitorsA into our data and usage:

6,000,000 Unique visitors every month

1,000,000 Translations

100,000 Questions and answers

25,000 Flashcards

5,000 Video pronunciations

90 Lessons

quick glance

Our Services

Node Other

API server Web site

Auto-suggest server Data mining

Translation server Operations

Text-to-speech server

Our TrafficVery low latency for our db-backed

services.

Service Reqs/min

API server 35K / min

Auto-suggest server 15K / min

Translation server 2.5K / min

Text-to-speech server 400 / min

Five Node.jsproduction tips

1. Know when to Node2. Keep up with Node3. Design for failure4. Isolate services5. Analyze everything

1. Know when toNode

Should you use Node.js?

YesSmall apps (think JSON APIs)

"Glue" for services or data

Proxies

Concurrent data

Use the module

Lots of connections

stream

Maybe notComputation

Legacy applications

"Solved" problems (fuzzy search, NLP,etc.)

2. Keep up withNode

Bleeding edge, lots of breakage.Stay up to date with Node.js and libraries.

Infrastructure

Node.jsdeployments

PAAS: Often, the easier way.

, , , etc.

IAAS: Expect some DIY

Build custom Node.js versions

Install modules from scratch

Get ready to roll back

Joyent Heroku Nodejitsu

3. Design for failureFail and recover at multiple levels.

App-levelErrors

Handle: uncaughtExceptionListen: foo.on("error")

Use the module

Workers: die early on errors

Master: monitor and kill workers

cluster

Server-levelUse or alternatives

Restart the Node.js master

monit

Service-levelHave lots of small apps

Stateless, fungible servers

Hot failover wherever possible

4. Isolate servicesSeparate resource and failure classes.

ResourcesCPU/Load: Run out of this and it's over.

Also, memory, I/O, etc.

... and combinations thereof

Our painsNode.js apps aren't necessarily good

neighbors.

Suggest (DB) and translate (http)

Backend (DB) and web site (CPU/load,memory)

Read and write servers

TakeawaysAlways preserve CPU

Monitor system stats for cross-pressure

5. Analyzeeverything

How well are we addressing lessons 1-4?Data drives problem discovery and action.

Log, Monitor, Mine

Things to look forSome metrics that affect Node.js apps

Type Metrics Uses

System CPU, I/O, memory,network

Alert

Server Throughput, latency Alert,Report

Traffic Peaks (weeks,months)

Report

Errors Quantitative,qualitative

Alert,Report

Decisions, GoalsIdentify

Resource pressure

Bugs

Decide

Scale up, scale down?

Separate?

Demo

Recap1. Know when to Node2. Keep up with Node3. Design for failure4. Isolate services5. Analyze everything

Further Reading by

by

by

Production Node.js Secrets@dshaw

Node.js in Production @felixge

Zero to Node @williamjohnbert

Thanks! | Ryan Roemer @ryan_roemer

@SeattleNode