Node and Azure

Editor's Notes

• #4: c10k - Ten Thousand Clients - solves problem through async IO
• #5: Libeio uses a threadpool to provide an async version of the POSIX IO libraries
• #6: Starbucks analogy Events: Order and then step aside until order is called Walmart - Threads: Order and wait until food is ready, no one else can order on that register until done Event LOOP - talk about it
• #8: Only the IO is non blocking. Compute bound operations (like calculating PI) will still block. Web apps shouldn’t be compute bound though.
• #9: Show example with setTimeout and c# (sleep.js and sleep.cs)
• #10: events1.js -- use telnet, not nc
• #11: addListener and on are synonymous once - removes listener the first time the event is received all methods return the emit so chaining is possible
• #12: events2.js MyEventClass.js
• #13: console example
• #17: http.js example
• #20: Connect has a router now
• #25: Supports filters
• #28: if empty was false, the last <p> tag would be gone
• #33: db.getUsers() - Remember, everything is a callback
• #34: Example... socketio express app
• #46: Unless otherwise noted below, all measurements were taken at server CPU utilization > 90%. The configuration involved one quad core Windows 2008 server with node.js v0.6.6 and iisnode v0.1.13. Depending on scenario, one or two WCAT client machines were required to saturate the server. Clients and server were connected to the same switch but were not on private network.   [1] See test code . In this scenario node.js application returns a simple “hello, world” plaintext response to an HTTP GET request. This is the only scenario that uses a single node.exe instance (both self-hosted and IIS hosted). Given the single-threaded nature of node.exe, the multi-core server CPU is never fully utilized. However, the node.exe process has consistently utilized > 23% of CPU, which corresponds to almost full utilization of a single core of the quad-core server.   [1.1] Although in this scenario iisnode achieved better throughput than self-hosted node.exe, it was accomplished with almost twice as large CPU utilization (~60% in case of iisnode compared to ~30% in case of node.exe).   [2] See test code . This scenario uses the same node.js “hello world” application as scenario #1, but it utilizes 4 node.exe processes to saturate the CPU on the quad core server. In case of self-hosting node.exe, the built-in cluster functionality is employed. In case of iisnode, the built-in capability to spawn and route to multiple node.exe processes per application is used.   [3] See test code . This scenario simulates using node.js to serve a web site using express - one of the most popular MVC frameworks for node. The web site consists of an HTTP endpoint that dynamically generates HTML that displays a randomly generated order information using the jade rendering engine. The HTML refers to a static CSS file. As part of each WCAT transaction, one request is made to the HTML endpoint that generates dynamic content and the another to get the static CSS file. In case of self-hosted node.js application, the static file is served by the express framework using the connect.static middleware (which is built into express and a most likely mechanism to be used by someone serving static content from express). In case of IIS, requests for static content are actually not handled by iisnode at all – a URL rewrite module causes that request to be handled by the native static file handler (which plays to the “side by side with other content types” benefits of iisnode).   [4] See test code . This scenario simulates using node.js to implement web APIs: HTTP endpoints that generate dynamic content. In this particular case we are reusing the order generation and HTML rendering endpoint from scenario #3, without including a request for static CSS file in the WCAT transaction.