Node.js in Production


Published on

The good, the bad, and the ugly technical details of running Node.js services for the world’s largest Spanish learning website,

Presented at the 5/8/2013 Seattle Node.js Meetup -

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Node.js in Production

  1. 1. Node.js inProduction-|Seattle Node.jsMay 8th, 2013Ryan Roemer @ryan_roemer
  2. 2. OverviewProduction!Well, what our production looks like.Five Node.js-related things wevelearned.Some additional resources.
  3. 3. What is"Production"?
  4. 4. Curiosity Media
  5. 5. Brought to youby...A team of three engineersWho are full-time developersRunning everything in the cloudWith minimal time available for ops
  6. 6.
  7. 7. Demo
  8. 8. A Spanish-EnglishDictionaryis the world’slargest Spanish-English dictionary,translation, and language learningwebsite. We develop and providereliable, accurate, easy-to-useresources for learning
  9. 9. Our visitorsA into our data and usage:6,000,000 Unique visitors every month1,000,000 Translations100,000 Questions and answers25,000 Flashcards5,000 Video pronunciations90 Lessonsquick glance
  10. 10. Our ServicesNode OtherAPI server Web siteAuto-suggest server Data miningTranslation server OperationsText-to-speech server
  11. 11. Our TrafficVery low latency for our db-backedservices.Service Reqs/minAPI server 35K / minAuto-suggest server 15K / minTranslation server 2.5K / minText-to-speech server 400 / min
  12. 12. Five Node.jsproduction tips1. Know when to Node2. Keep up with Node3. Design for failure4. Isolate services5. Analyze everything
  13. 13. 1. Know when toNodeShould you use Node.js?
  14. 14. YesSmall apps (think JSON APIs)"Glue" for services or dataProxiesConcurrent dataUse the moduleLots of connectionsstream
  15. 15. Maybe notComputationLegacy applications"Solved" problems (fuzzy search, NLP,etc.)
  16. 16. 2. Keep up withNodeBleeding edge, lots of breakage.Stay up to date with Node.js and libraries.
  17. 17. Infrastructure
  18. 18. Node.jsdeploymentsPAAS: Often, the easier way., , , etc.IAAS: Expect some DIYBuild custom Node.js versionsInstall modules from scratchGet ready to roll backJoyent Heroku Nodejitsu
  19. 19. 3. Design for failureFail and recover at multiple levels.
  20. 20. App-levelErrorsHandle: uncaughtExceptionListen: foo.on("error")Use the moduleWorkers: die early on errorsMaster: monitor and kill workerscluster
  21. 21. Server-levelUse or alternativesRestart the Node.js mastermonit
  22. 22. Service-levelHave lots of small appsStateless, fungible serversHot failover wherever possible
  23. 23. 4. Isolate servicesSeparate resource and failure classes.
  24. 24. ResourcesCPU/Load: Run out of this and its over.Also, memory, I/O, etc.... and combinations thereof
  25. 25. Our painsNode.js apps arent necessarily goodneighbors.Suggest (DB) and translate (http)Backend (DB) and web site (CPU/load,memory)Read and write servers
  26. 26. TakeawaysAlways preserve CPUMonitor system stats for cross-pressure
  27. 27. 5. AnalyzeeverythingHow well are we addressing lessons 1-4?Data drives problem discovery and action.
  28. 28. Log, Monitor, Mine
  29. 29. Things to look forSome metrics that affect Node.js appsType Metrics UsesSystem CPU, I/O, memory,networkAlertServer Throughput, latency Alert,ReportTraffic Peaks (weeks,months)ReportErrors Quantitative,qualitativeAlert,Report
  30. 30. Decisions, GoalsIdentifyResource pressureBugsDecideScale up, scale down?Separate?
  31. 31. Demo
  32. 32. Recap1. Know when to Node2. Keep up with Node3. Design for failure4. Isolate services5. Analyze everything
  33. 33. Further ReadingbybybyProduction Node.js Secrets@dshawNode.js in Production @felixgeZero to Node @williamjohnbert
  34. 34. Thanks!|Ryan Roemer @ryan_roemer@SeattleNode