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.
Brought to youby...
A team of three engineers
Who are full-time developers
Running everything in the cloud
With minimal time available for ops
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.
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
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
Recommended
