Nodejs @ Yahoo
Upcoming SlideShare
Loading in...5
×
 

Nodejs @ Yahoo

on

  • 1,748 views

Presentation given as an internal tech talk to share our early Node.js efforts and experience in our Beijing R&D Center.

Presentation given as an internal tech talk to share our early Node.js efforts and experience in our Beijing R&D Center.

Statistics

Views

Total Views
1,748
Views on SlideShare
1,726
Embed Views
22

Actions

Likes
2
Downloads
23
Comments
0

4 Embeds 22

http://paper.li 16
http://www.linkedin.com 4
http://nodeslide.herokuapp.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Nodejs @ Yahoo Nodejs @ Yahoo Presentation Transcript

  • @ Yahoo! Fabian Frank <frankfa@yahoo-inc.com>UIE Front-End: Search Direct, SearchX (PHP, node.js) spare time: youthmedia.eu (Rails)
  • ????????
  • Prefork/Worker Model• A set of N workers (Threads, Processes)• An incoming connection is assigned to a worker and the worker is now “in use” until the connection drops, even if it is only waiting• OS timesharing enables serving much more connections at the same time than CPUs are available, at the expense of context switching• If all workers are in use, incoming connection waits (and average response time rockets)
  • non-blocking IO has been around for a long time• int read(int FD, char* buf, int len); • returns after reading at least 1 byte • what one uses normally• int aio_read(struct aiocb* {int FD; char* buf; int len}); • use aio_error(struct aiocb*) to check if the read finished, if yes then call aio_return() • select or kqueue appeared later (year 2000)
  • Event Oriented Model• An incoming connection (or data) triggers an event, which is put on top of the event queue• Whenever processing of one event has finished, receive the next event from the event queue• No built-in or OS timesharing, one process
  • • Event-oriented• JavaScript on V8, because authors gave up on Ruby due to performance constraints• single-threaded by design, but several node processes can run at the same time leveraging several cores• event oriented HTTP and TCP implementation for Server and Client• (a)synchronous file system access
  • V8• JavaScript Engine written in C++ for Google Chrome• JavaScript is compiled into machine code before execution• Embeddable into custom C++ applications• Garbage collection by stopping program flow and removing all objects without references
  • Demo• A small event based server
  • Awesomeness in Node.js• JavaScript - the good parts• Same language on server and client• Event oriented model scales very well with increasing concurrency and network IO• You can actually send your application and its state (JSON) to the client, where it continues execution
  • Pitfalls in Node.js• Scales badly with computational complexity • Web workers API implementation promised• Same language, but still the game on the server is a different one• JavaScript - the bad parts • hopefully ES5 strict can help
  • YNodeJS• Multi-core support• Modules for YIV,YDOD,YCK, etc.• Implements open_basedir restrictions like PHP
  • Stability Considerations• Following the prefork model, you only lose 1 connection when a worker dies • or a few if you have several threads per process• Following the event oriented model, you lose all connections when your process dies • or half, a quarter, etc. depending on the number of processes
  • Server Side YUI• YUI is fully functional• Creating a YUI instance with module loading is very slow • can be dealt with using caching• Y.io is significantly slower than http.request • just use http.request if performance matters• Overhead of adding a framework vs. performance
  • Manhattan• Node.js cloud service• Deploy applications with one command
  • Search Direct Modules Case Study• Right Panel retrieved using AJAX• { ‘html’: ‘<div>...</div>’, ‘css’: ‘...’, js: ‘...’, ... }
  • SD: Characteristics• Simple request (query and ~3 other parameters that matter)• Retrieve data from always 1 back-end, aggressive timeout• Render a small piece of HTML, put it in a JSON object with some string constants• A lot of concurrent requests (one request per character that is being typed in a Y! search box)
  • Scalability• PHP based solution has an average response time of >100ms for 50 concurrent connections
  • Scalability• PHP based solution has an average response time of >100ms for 50 concurrent connections
  • Scalability• PHP based solution has an average response time of >100ms for 50 concurrent connections
  • Conclusion• Node.js can deliver great performance and scalability in our use case• The Mustache templating engine adds minimal extra latency, which indicates strong JS performance• Using YUI via a global shared instance is fine, but creating an instance per request is currently not feasible
  • See you on nodejs-users@ !
  • References• $ man aio aio_read aio_error aio_return• http://www.freebsd.org/releases/3.0R/notes.html• http://www.freebsd.org/releases/4.1R/notes.html• http://www.nodejs.org/• http://www.yuiblog.com/blog/2010/04/05/running- yui-3-server-side-with-node-js/• http://mustache.github.com/• http://code.google.com/apis/v8/embed.html