Wednesday, May 21, 2014

longjohn

Using longjohn couldn't get any easier. You just need to require('longjohn') and you are all set. The magic that I mentioned above consists of replacing functions like setTimeout and nextTick with patched versions that keep track of the stack as it unfolds and as author suggests, this probably shouldn't be used in production.
MoreInfo
npm reference

Monday, May 19, 2014

NGINX as a WebSockets Proxy

The WebSocket protocol provides a way of creating web applications that support realtime bi-directional communications between clients and servers.  Part of HTML5, WebSockets makes it much easier to develop these types of applications then the methods previously available.  Most modern browsers support WebSockets including Firefox, Internet Explorer, Chrome, Safari and Opera and more and more server application frameworks are now supporting WebSockets as well.
For enterprise production use, where multiple WebSocket servers are needed for performance and high availability, a load balancing layer that understands the WebSocket protocol is required, and NGINX has supported WebSockets since NGINX 1.3 and can act as a reverse proxy and do load balancing of WebSocket applications.
The WebSocket protocol is different than the HTTP protocol, but the WebSocket handshake is compatible with HTTP, using the HTTP Upgrade facility to upgrade the connection from HTTP to WebSocket.  This allows WebSocket applications to more easily fit into existing infrastructures.  For example, WebSocket applications can use the standard HTTP ports 80 and 443, thus allowing the use of existing firewall rules.

Monday, May 5, 2014

Optimization killers in Node.js

This  link will contain advice to avoid writing code that will perform significantly worse than expected. Specifically those patterns that cause V8 (relevant to Node.JS, Opera, Chromium...) to refuse to optimize the affected function.

Some V8 background

In V8 there is no interpreter but there are 2 different compilers: generic and optimizing. That means your Javascript is always compiled and run directly as native code. That means it's fast, right? Wrong. Code being compiled to native code by itself isn't hugely significant for performance. It just removes interpreter overhead but the code will still be slow if not optimized.

Sunday, May 4, 2014

How-to: Heap Snapshots and Handling Node.js Memory Leaks

Node memory leaks happen. Usually they occur in production where processes experience the weight of their purpose and a mandate for up time. Thankfully, the core of Node is becoming more and more resilient to leaks. However, between our code and the modules we include, leaks still happen and it’s good to be prepared to handle them ...  More Info