How Node.js Revolutionized the Retail Space

In a crowded world of popular computer languages, platforms and ecosystems, Node.js is one of the hottest. According to w3techs.com, Node.js usage has gone up 241 percent in the last year alone. Retailers have taken notice and are implementing it on many levels. I am going to share the basics of Node.js, and discuss why retailers are using it to reduce page load times and improve server efficiency. I’ll talk about similar developments such as Docker and microservices, and look at several companies implementing these technologies. I’ll also discuss how mobile computing is changing buyer behavior and expectations.

Distributed Devices

I believe one of the main reasons retail stores and related businesses are embracing Node.js is due to its ability to build data-intensive apps that can run in real time across a spectrum of distributed devices. Also, its performance is much faster for high-traffic applications than other traditional languages, such as Java. As consumers continue to shop more from their mobile devices, these factors are increasingly important. Bob Sherwin, a senior marketing director at Wayfair LLC, told Internet Retailer magazine that only a year ago customers would research products on their handset, but make the actual purchase from their desktop computer or tablet. Now they are comfortable making purchases right from their smartphone, increasing the need for stronger support from the web APIs these devices interface with.

Mobile Sales Growing Fast

These changes in buying behavior on mobile devices are leading retailers to re-evaluate their approach to mobile marketing. Mobile sales are growing fast — Goldman Sachs estimates that worldwide commerce sales on mobile devices will reach $415 billion in 2016, rising to $626 billion in 2018. Experts expect mobile sales to continue growing at a furious pace because they are currently expanding at twice the rate of e-commerce sales. However, these numbers only reflect actual purchases. When research and browsing time is factored in, mobile’s role in retail sales takes on even greater impact.

Node.js On the Rise

Node.js strengths in retail include:

  • The ability to handle many connections at the same time, which reduces operating costs.
  • Hundreds of thousands of modules currently available in the official Node.js package manager, which makes it easy for developers to build apps quickly rather than starting from scratch each time.
  • Its ability to use resources on the server as they are needed, reducing its footprint considerably.
  • Its efficiency and the way it increases productivity gains. Node.js is a natural for agile development as it only needs one-third to one-half the lines of code to complete a job.
  • Its speed. Node.js is built on Google’s JavaScript V8 runtime engine. Google made V8 available to other projects when they made the code open source.
  • The fact that it allows developers to test different options quickly. When Netflix was trying to figure out the best way to let Sony Playstation 3 users download movies, they came up with four different interfaces for testing. The interface that won was not even a favorite of the programming team.

Retailers and related companies using Node.js include:

  • LinkedIn. LinkedIn was an early Node.js evangelist. They abandoned Ruby on Rails for Node.js back in 2011. Today, the entire stack is driven by Node.js. Speeds improved up to 20 times, and server count was reduced from 30 to three.
  • Uber. Uber completely changed their web layer to Node.js to improve efficiency and create a better experience for customers and partners. Node.js replaced a LAMP stack with PHP and MySQL. PHP did not scale well and produced unacceptable bugs — there were errors like double-dispatching which sent two cars to one customer. They decided to separate the business logic from the dispatch system that operated in real time. Node.js was selected to bring the system up to date and be able to handle more connections efficiently.
  • Groupon. Groupon was another high profile e-commerce company who left Ruby on Rails behind for Node.js. Was it worth it? They noticed page load times improved 50 percent and are now able to develop new features quicker.

Supplementing Node.js to Node.js

Node.js is just one of several rapidly developing technologies that retailers are using. Docker, microservices, and agile development are also high on the list for retail and e-commerce companies.

  • Docker. Docker is an open-source project that packages an app and its dependencies in a container.
  • Microservices. Microservices is a process of building a large app as a system of small, modular services. Each microservice has a business purpose and uses simple methods to communicate with other services.
  • Agile Development. Developing software through cross-functional teams using continuous improvement and rapid planning and implementation.

For example, here are examples of retailers and sales-oriented companies who have used these technologies.

  • Shopify. Shopify implemented Docker to make their data centers more adaptable and easier to maintain. Shopify primarily relied on Ruby on Rails to handle thousands of requests per second spread over 1,700 cores. However, as Docker’s popularity began to expand, Shopify considered it for several benefits, including scaling up several servers quickly to handle traffic surges, using spare capacity in server farms for heavy-duty operations, and the ability for several containers to do different work on the same hardware with no interference.
  • Salesforce. Agile development is not new, but more companies are in the process of improving their agile methods. Twitter and Salesforce are two high-profile companies that rely on agile development for shorter cycle times, reduced bottlenecks and increased productivity. The key is self-organized teams with dedicated resources who can continually iterate their approach. They work under principles such as minimal work-in-progress and continuously releasable products that rely on automation to help keep everything lean.

Node.js shines, since it can be rapidly reconfigured and will adapt quickly to high-demand environments. Just as they have with other newer architecture design-patterns, like Docker and microservices, I soon expect to see more retailers using Node.js. We are now living in a high-traffic world, so retailers that can meet customer needs quickly and efficiently will garner more sales and profits in the process.

Top Performance Metrics for Java, .NET, PHP, Node.js, and Python

No application is the same. Some legacy apps were built in a monolithic environment built on a homogeneous language, say Java or .NET. As environments become more distributed, and technology has innovated to a near-breaking speed, application architectures tend to be built using a multitude of languages often leveraging the more dynamic languages for specific use cases.

Luckily, these distributed and extremely complex environments are where AppDynamics thrives with monitoring. AppDynamics supports Java, .NET, PHP, Node.js, Python, C/C++, and any combination of them — fitting nearly any environment.

After speaking with several customers and analyzing their performance, we’ve compiled a list of the most common performance problems for each language and the performance metrics to help measure your application health.

Below, we’ve compiled a brief summary of our findings and link to the full analysis in the respective complimentary eBooks.

Top Java Performance Metrics

Java remains one of the most widely used technology languages in enterprise applications. However, though it’s so widespread, it’s a clunky legacy language that can often have performance issues.

Along with monitoring external dependencies, garbage collection, and having a solid caching strategy, it’s important to measure business transactions. We define a business transaction as any end-user interaction with the application. These could include adding something to a cart, logging in, or any other interaction. It’s vital to measure the response times of these transactions to understand fully your user experience. If a response time takes longer than the norm, it’s important to get this resolved as quickly as possible to maintain optimal user experience.

Read the full eBook, Top 5 Java Performance Metrics, Tips & Tricks here.

Top .NET Performance Metrics

There are times in your application code when you want to ensure that only a single thread can execute a subset of code at a time. Examples include accessing shared software resources, such as a single threaded rule execution component, and shared infrastructure resources, such as a file handle or a network connection. The .NET framework provides different types of synchronization strategies, including locks/monitors, inter-process mutexes, and specialized locks like the Reader/Writer lock.

Regardless of why you have to synchronize your code or of the mechanism you choose to synchronize your code, you are left with a problem: there is a portion of your code that can only be executed by one thread at a time.

In addition to synchronization and locking, make sure to measure excessive or unnecessary logging, code dependencies, and underlying database and infrastructure issues.

Read the full eBook, Top 5 .NET Performance Metrics, Tips & Tricks here.

Top PHP Performance Metrics

Your PHP application may be utilizing a backend database, a caching layer, or possibly even a queue server as it offloads I/O intensive blocking tasks onto worker servers to process in the background. Whatever the backend your PHP application interfaces with, the latency to these backend services can affect the performance of your PHP application performance. The various types of internal exit calls may include:

  • SQL databases
  • NoSQL servers
  • In-memory cache
  • Internal services
  • Queue servers

In some environments, your PHP application may be interfacing with an obscure backend or messaging/queue server. For example, you may have an old message broker serving as an interface between your PHP application and other applications. While this message broker may be outdated, it is nevertheless part of an older architecture and is part of the ecosystem in which your distributed applications communicate with.

Along with monitoring the internal dependencies, make sure you measure your business transaction response time (as described above), external calls, and have an optimal caching strategy with full visibility into your application topography.

Read the full eBook, Top 5 PHP Performance Metrics, Tips & Tricks here.

Top Node.js Performance Metrics

In order to understand what metrics to collect surrounding Node.js event loop behavior, it helps to first understand what the event loop actually is and how it can potentially impact your application performance. For illustrative purposes, you may think of the event loop as an infinite loop executing code in a queue. For each iteration within the infinite loop, the event loop executes a block of synchronous code. Node.js – being single-threaded and non-blocking – will then pick up the next block of code, or tick, waiting in the queue as it continue to execute more code. Although it is a non-blocking model, various events that potentially could be considered blocking include:

  • Accessing a file on disk
  • Querying a database
  • Requesting data from a remote webservice

With Javascript (the language of Node.js), you can perform all your I/O operations with the advantage of callbacks. This provides the advantage of the execution stream moving on to execute other code while your I/O is performing in the background. Node.js will execute the code awaiting in the Event Queue, execute it on a thread from the available thread pool, and then move on to the next code in queue. As soon as your code is completed, it then returns and the callback is instructed to execute additional code as it eventually completes the entire transaction.

In addition to event loops, make sure to monitor external dependencies, memory leaks, business transaction response time, and have a full and complete view of your application topography.

Read the full eBook, Top 5 Node.js Performance Metrics, Tips & Tricks here.

Top Python Performance Metrics

It is always faster to serve an object from memory than it is to make a network call to retrieve the object from a system like a database; caches provide a mechanism for storing object instances locally to avoid this network round trip. But caches can present their own performance challenges if they are not properly configured. Common caching problems include:

  • Loading too much data into the cache
  • Not properly sizing the cache

When measuring the performance of a cache, you need to identify the number of objects loaded into the cache and then track the percentage of those objects that are being used. The key metrics to look at are the cache hit ratio and the number of objects that are being ejected from the cache. The cache hit count, or hit ratio, reports the number of object requests that are served from cache rather than requiring a network trip to retrieve the object. If the cache is huge, the hit ratio is tiny (under 10% or 20%), and you are not seeing many objects ejected from the cache then this is an indicator that you are loading too much data into the cache. In other words, your cache is large enough that it is not thrashing (see below) and contains a lot of data that is not being used.

In addition to measure your caching, also, monitor your external calls, application visibility, and internal dependencies.

In addition to measure your caching, also monitor your external calls, application visibility, and internal dependencies.

Read the full eBook, Top 5 Python Performance Metrics, Tips & Tricks here.

To recap, if you’d like to read our language-specific best practices, please click on one of the links below:

Battle of the PaaS: Node.js Apps in the Cloud

No matter why you came to Node.js to develop your app (blasting past slow I/O, free data exchange, moving out of the Flash sandbox, etc.) what you want to know now is the best place to host it. The answer to that question, though, really depends on what you want to do when you get to the cloud which involves your original intent for the app.

Unless you have your own IT department, PaaS beats self-hosting in a variety of ways. Your app will be able to handle surges in traffic inside data centers that are high-powered and geographically distributed. PaaS comes pre-built with all of the programming languages, frameworks, libraries, services and tools that your app is going to need as it grows and evolves. Before we get there, though, we should review some of the issues around how a typical Node.js app is deployed.

Getting Ready for Deployment

As you develop in Node.js, you’ve probably become familiar with the active and enthusiastic community of JavaScript developers that have already faced many of your issues. Although there’s plenty of free support for development end of Node.js, there’s not anywhere near that amount when you get to the deployment. Each hosting environment tends to offer its own advice on the right way to deploy.

Many developers use tools like the Node Package Manager to get their packages ready for deployment. On the other hand, if you end up deciding on a PaaS like Heroku, go directly to the PaaS deployment support site (for example, take a look at Heroku Dev Center) to get step by step instructions for getting your app up and running, along with any advanced features you may need to access.

Top PaaS Destinations for Your Apps

1. Heroku

Heroku has a well-deserved reputation for making deployment easy, as you may have seen if you went to the above link to their dev center. It was built by Ruby developers for Ruby developers, but this has proven to be just as useful for Node.js apps. Although a good choice for beginning developers, Heroku has also been chosen for its simplicity in hosting larger commercial projects like Faces of NY Fashion Week and National VIP.

Pros:

  • 24 hour monitoring. You have professional status monitoring, including a frequently updated Status Site.
  • Low cost to start. You can use Heroku for free at the entry level with 512 MB RAM and one web for one worker.
  • Portability. It uses standard tools, so it is easy to pack up and move to another host if necessary.
  • Integration. You can use Heroku with several third parties, such as MongoDB and Redis.
  • Popularity. Heroku lists Macy’s and MalwareBytes among its users, as well as several smaller companies. Its popularity also means that there’s a broad range of supported plugins to choose from.

Cons:

  • Lack of control. The simplicity comes at the cost of freedom to select the precise configurations such as hardware, OS, and firewall.
  • Steep price jump. When you are ready to move up to the professional level of support, the costs can be much higher than the competition.
  • Limited performance. The fact that it was designed for Ruby on Rails means that Node.js apps can show performance strains.

Best for:

Heroku is the best choice for beginner Node.js developers and those who want to get online fast with ample support. Many open-source advocates around the world swear by Heroku. It is pretty common to deploy to Heroku and once the app begins to get serious traffic, migrate to a PaaS with more freedom

2. Modulus

Modulus is likened to a “bicycle with a jet engine attached to it”. Born from developers originally trying to build a game in Node.js, they were frustrated with the lack of Node.js hosting options. So, they built their own premier Node.js hosting platform. Modulus has become more popular among startups such as Habitat and iChamp.

Pros:

  • Excellent Support. Modulus understands that building a loyal customer base takes time and dedication. There are several ways to contact support, and user reviews consider them to be very helpful.
  • Automatic Scaling. For those of you who mainly want to focus on the bare-bones building process, Modulus provides auto-scaling – one less thing to worry about during the day-to-day management of your app. For those who like a little more control, this feature is entirely optional.
  • Simplicity. Modulus is incredibly easy to use and is, therefore, suitable for absolute beginners. They have an app of their own which allows users to track statistics and manage their app on-the-go.

Cons:

  • Price. Unlike other PaaS solutions, Modulus has no free tier. At the very minimum (1GB file storage, 64MB database, 1 server) you will still be paying $7.20 per month. However, the higher data bands are not overpriced, and there is a free trial available (although it does not last long).
  • Smaller user base for support.

Best for:

Modulus is another good PaaS for start-ups and beginning developers. They have excellent customer support, a simple interface, and very few issues, which would make them a great choice to those of us who are only dipping our feet into the PaaS world – if it were not for the sheer cost of their services. A big draw of using a PaaS is that you are usually spending less money on hosting, and yet, with no free tier, Modulus is the most expensive option featured on this list. It is up to you whether you think the significant ‘pros’ of using Modulus are worth it.

3. Microsoft Azure

Many developers tend to shy away from Microsoft due to the portability issues, but Azure is a solid PaaS offering with plenty of functionality. The Azure’s site points out that more than 66 percent of Fortune 500 companies, 10,000 customers per week, rely on their 22 regional data centers for app hosting.

Pros:

  • Pay-as-you-use pricing. Microsoft Azure offers three different payment plans, each one tailored to the user’s needs. The basic app service is free.
  • Microsoft Azure works with other Microsoft services such as Visual Studio and WebMatrix.
  • Security. Microsoft Azure takes security very seriously. It uses penetration testing and even offers that same service to its customers. It also uses in-house security, instead of relying on Amazon Web Services.
  • Scale and performance. Microsoft Azure works with a specific set of runtime libraries, which creates excellent scaling and performance. However, this does create a risk of lock-in.

Cons:

  • Dealing with Windows. You’ll need to ensure you use npm install for all dependencies in case you need to compile C code on Linux, Mac or Windows since you can’t transfer a precompiled binary from one OS/architecture to another.
  • Risk of ‘lock-in.’ Microsoft Azure requires tailoring your code to the PaaS, which means that migration to another PaaS can be difficult.
  • Poor support. Despite their popularity, Microsoft Azure is lacking in the support department. Users report that getting hold of support was challenging, and the documentation provided is over two years old.

Best for:

Microsoft Azure is best for large scale projects. It has advantages in terms of pricing, security, and functionality. However, it comes at the price of being difficult to migrate in from other OS environments and out to other PaaS options. You might be concerned about the level of support if you a developer new to the Node.js environment.

4. Linode

Linux users have been significant supporters of Linode for more than a decade. It has seen a good deal of upgrades and developments in the past couple years, so it is a reliable choice. Linode features a hub of high-performance SSD Linux servers for variable coverage of infrastructure requirements. They now offer a 40-gigabit network with Intel E5 Processors and support for Ipv6.

Pros:

  • Active development. Linode recently added features like the Longview server monitoring. It is capabilities are evolving rapidly.
  • Linux user base. The community of Node.js developers is supported by a wider community of Linux user who can troubleshoot most issues you encounter.
  • Free upgrades. The base level has been upgraded to offer 1GB ram, 48GB storage, and 2TB transfer. Long time users will see their capabilities grow with regular upgrades.

Cons:

  • Server attacks. Last Christmas, Linode was plagued with DDoS attacks. While it was not their fault, their reputation suffered for it. Linode managers blamed the size of the data center as one reason it is an attractive target.
  • No control panel. You have to configure your own virtual hosting. You will not be able to run CPanel or Plesk, so you have to be pretty comfortable with command line controls.

Best for:

Linode devotees tend to be pretty enthusiastic about it. If you are an experienced developer and want the support of a robust Linux community that goes beyond development, this is an excellent destination for your apps. Be aware that they may continue to be a target for hackers, but you can enjoy watching the latest technologies evolve on their servers.

Concluding Checklist

If you are a beginning developer or a startup: go with Heroku or Modulus. If cost or portability is a concern, start with Heroku.

If you are working in a team on a larger, collaborative project, particularly on Windows machines, Microsoft Azure is extensive enough to handle just about anything you can create.

If you are an advanced Linux aficionado with a deep interest in testing out the bounds of new technology as it appears, go with Linode.

WordPress Announces Migration to Node.js

Matt Mullenweg, the CEO of Automattic, the parent corporation of WordPress, generated a lot of excitement when he announced recently that WordPress.com was beginning to migrate away from PHP to JavaScript and Node.js in particular. Why would the No. 1 content management system in the world make such a major change? Could this negatively affect the more than 74 million WordPress websites on the Internet?

What Is Node.js?

Node.js is a single threaded, non-blocking, open-source JavaScript runtime environment. It is also one of the fastest-growing projects on the Internet, and it was originally created in 2009 by Ryan Dahl and a team of developers at Joyent. It is powered by Google Chrome’s V8 JavaScript runtime and uses a non-blocking, event-driven I/O that lets you rapidly create fast, efficient and scalable applications.

Node.js is particularly well-suited for real-time applications that are data intensive. It also plays well across distributed devices. With Node.js, you can create applications for the server and JavaScript, much like you would in other programming languages like Python. JavaScript is ideal for this environment because it is already well-known to client-side developers, and it handles I/O applications with aplomb. Currently, JavaScript is primarily used as a lightweight language interpreted by browsers once a Web page loads.

Why Go From PHP to Node.js?

If PHP has been rock solid for so many years, what specific things does Node.js do for WordPress that prompted the change? Specifically, it offers these advantages:

  • Node.js is fast because it is asynchronous and non-blocking. Synchronous systems that use blocking are slower because each request must be served in turn.
  • Node.js was built around modern computing architectures. It is not hampered by decades-old legacy code.
  • JavaScript is a modern language that can be molded and extended in a myriad of ways.
  • Node.js “speaks” JSON, allowing developers to use a single syntax from the web browser through the server to the database.
  • Node.js makes event loops available on the server. You can quickly write applications to do things like connecting databases to powerful Web APIs.

Node fits the needs of a fast-changing Internet that is increasingly mobile. The Web is becoming ubiquitous, as we see it implemented in everything from appliances to clothing. Node.js is more suited to that environment than PHP.

Two Major Challenges

When Matt Mullenweg became CEO of Automattic in January of 2014, he realized the WordPress project had two major challenges:

  • Lack of capital
  • Limits of current technology

It was the second reason that led him and the Automattic team to consider new approaches. The current codebase has helped the platform grow rapidly–currently, 25 percent of websites on the Internet are powered by WordPress. It is powerful, flexible and cheap to run.

Backward Compatibility

However, one of the downsides has been the area of administration. Mullenweg felt the strengths of WordPress were also creating weaknesses for wp-admin–the administration section of WordPress–and they needed a new plan for the future.

One of the main challenges was that they needed to step away from backward compatibility to get a fresh start, yet one of the platform’s strengths has always been that it was compatible with every release. In contrast, some other popular content management systems like Drupal routinely broke backward compatibility to be able to use the latest technology bells and whistles. It didn’t always make users happy, but it kept the platform on the cutting edge.

Worldwide Contributors

More than 120 contributors combined efforts over many months to meet this challenge, and the result is Calypso. Project Calypso was in-house effort at Automattic to rethink the WordPress codebase and see where it could be improved. Adding Node.js was a natural fit, yet few of the team members in the organization were strong JavaScript coders. However, through trial and error, they began to succeed, and the original handful of developers grew to 127 with more than 26,000 commits.

100 Percent Open Source

Calypso is 100 percent open source, written using libraries from Node.js and React.js. React.js, originally created by developers at Facebook to build user interfaces that worked across many platforms, is used for the user-facing front end.

Node.js is used to make the back end. It is entirely driven by open APIs available to everyone. A single-page application (SPA) runs in the client, taking advantage of multiple JavaScript modules.

REST APIs

Calypso is entirely driven by open representational state transfer (REST) APIs that are available to everyone. The open API means you can manage any of your sites through Calypso. It is blazing fast with pages that load almost instantly, and you can now employ social features like statistics and notifications.

Multi-Site Management

One of WordPress’ strengths is the ability to run multiple sites off the same database. However, managing many blogs can be daunting. Calypso lets you manage many WordPress sites from one administration screen off of any desktop computer, smartphone or mobile device.

Currently, Calypso is deployed on WordPress.com, the site that hosts many free WordPress blogs. Just how big is WordPress.com? Consider these numbers. In 2014:

  • More than 18 million new blogs were created–that’s about 50,000 per day
  • More than 550 million posts were published–that’s the equivalent of 1.5 million per day
  • 47 million posts were originated from mobile devices

Self-Hosted WordPress Sites

If you have a self-hosted WordPress site, you can still take advantage of Node.js developments through the Jetpack plugin. To make it work, you must have a WordPress.com account. Jetpack connects to WordPress.com, which allows you to:

  • Edit and administrate all of your blogs
  • Manage pages, posts, themes, menus, plugins and various settings
  • Write and edit posts very quickly

There is also an application available for Macintosh OS X, with other platforms like Windows to be released soon.

Uncharted Waters

Is WordPress moving into uncharted waters? Not entirely. There are blogging platforms that already use Node.js extensively. One example is Ghost, called by some enthusiastic backers the “WordPress killer,” when it was released in 2012. Ghost was originally built with Backbone, a lightweight JavaScript framework that uses Underscore.js as its single JavaScript library, and the Handlebars semantic templating engine. The developers then transitioned to the Ember.js platform for the client-side and Node.js for the server, while retaining SQL for databases.

First Step Forward

Calypso is the first step in what many see as a continuing move of WordPress.com from the safe harbors of PHP and MySQL. In effect, the site is becoming a client for the API, similar to any application that uses the API. That makes it speedier and lighter for the mobile computing environment that is taking over the world.

With Calypso and Node.js, end users can expect a better experience with WordPress–pages will load faster and respond snappier. Users that also function as webmasters on their own blogs will benefit from new tools for:

  • Multi-site management
  • Desktop blogging
  • Statistics and analytics
  • Website security
  • Site monitoring
  • Image delivery via CDN
  • Stunning Slideshows
  • Improvements in sharing capability

Although these features will allow a significant percentage of general users running self-hosted blogs to use Jetpack to replace much of their current plugins, power users will demand more power and the ability to tweak settings and configuration. For that reason, advanced users will more than likely stay with the majority of their plugins.

The Future of PHP and Node.js

The vast world of WordPress wondered if Calypso was a harbinger of things to come. Would all of WordPress eventually run on Node.js? According to Mullenweg, Calypso shows what is possible. In an interview with Venture Beat, he said he thinks the technology behind the server side and the client side will probably split. PHP is still dominant on the server side, but Calypso and JavaScript, much like Node.js, is the way of the future for the client side.

Does the implementation of Node.js mean the death knell of PHP? If so, it will take some time. PHP is a tough racehorse and has been carrying WordPress around the track for 13 years.

Eventual Takeover

Node.js may take over PHP eventually — it has made huge inroads:

  • After a successful Black Friday test, Walmart began moving their mobile traffic to Node.js.
  • Early on, Yahoo started to migrate to Node.js for their Web stack.
  • LinkedIn reported giant performance gains when they began implementing Node.js.

At this point, Calypso is an administration area with a dashboard. It’s really a combination of React.js with Node.js sitting on the server to generate the Web page. It then talks to the WordPress site through a REST API, and the site is still written in PHP.

However, the future of computing is mobile, and Node.js is a clear winner on distributed devices and the Internet of Things. The way forward isn’t entirely clear, but you can expect Node.js to be in the driver’s seat for a very long time.

Running a Node.js app? Make sure to check out my Node.js Cheat Sheet.

A Practical Guide to Popular Node.js MVC Frameworks

Using any programming framework to the fullest extent possible first requires an understanding of advanced software architecture concepts. While writing a little client-side JavaScript does not necessarily require as much consideration when designing a scalable software architecture, the evolution of tools like Node.js means that you could be facing large code bases that must be easy to maintain.

Modern JavaScript frameworks take advantage of programming principles that have long been part of other languages, including software architecture patterns like model-view-controller. The value of work with frameworks that come with a pattern like MVC baked in is that the framework will do much of the work of managing the interactions between different sections of your code. You can write just the code you need for your particular application, such as code controlling what data the application outputs while the framework handles connecting that component of your application to the component that accepts and translates input.

JavaScript offers a benefit to working with these sorts of architectural patterns: because Node.js allows you to run JavaScript on your server, as well as on the client side, you can maintain a pattern like model-view-controller across your entire application.

MVC: The Software Architecture Pattern You Need to Know

The model-view-controller pattern of designing software (also known as MVC) was one of the first architectural design-patterns based on the responsibilities of its component software constructs. Trygve Reenskaug introduced the concept of MVC while visiting Xerox Parc (the same research facility that pioneered everything from GUIs to laser printers) in the 1970s.

MVC was revolutionary then and is still a key concept when discussing how to create new software. When using an MVC pattern, you can lay out the solution to any problem you expect to solve with the software you intend to build. The three components included by name in the pattern are:

  • The model, which describes the behavior of the application regarding data, logic, and rules

  • The view, which includes any information that the application may output (from tabular data to representations)

  • And the controller, which accepts and translates input

Note that the model, which is the core component on which you will wind up focusing, is independent of any user interface you are planning to create eventually.

In addition to these three elements, the MVC model sets out the interactions you’ll see between the components.

  • The model will store any data that is displayed in the view and stores data that the controller instructs the model to retrieve

  • The view generates an output based on changes to the model

  • The controller updates the model’s state and can also update the view’s presentation of the model

When using the MVC pattern to design software, you need to consider both the components and the interactions.

JavaScript Puts the View in MVC

JavaScript frameworks primarily improve your ability to write code for your users’ browsers. These frameworks consist of client-side code that you may consider to be most closely tied to view components (including any information your application may output).

Ember, Angular, Backbone, and React all excel at controlling view components. Some of these frameworks, such as Ember and Backbone, can also handle some elements of the controller — they can send instructions back to the code on the server and update it.

Provided you are focusing primarily on the browser, these four frameworks are likely to be your best options.

  1. Ember.js: This web application framework offers a straightforward feature set that will work for most projects. It may be the most friendly for a programmer coming from another language, such as Python or Ruby, especially for a developer used to using the MVC pattern. However, what may be the biggest deciding factor, Ember.js provides high application performance.

  1. AngularJS: The community working around AngularJS is incredibly active, making it a good option just by virtue of the tutorials, plugins, and other community-generated tools now available. That community is augmented by Google’s backing, helping AngularJS be a real contender among JavaScript frameworks.

  1. Backbone.js: One of the main advantages offered by this framework is its relatively small size though it gains that size at the expense of individual features. However, even with adding additional tools to the mix, Backbone.js tends to offer some of the best page load times. The result is a lean, minimalist framework that’s easy to learn.

  1. React: Facebook open-sourced one of their JavaScript libraries as the basis for React and have continued to add to it. The result is a high-performance library. It is a little less full-featured than the frameworks above, but as the React website describes, “lots of people use React as the V in MVC.” The community around React is growing, due to the upcoming release of AngularJS 2.0, which will not be backwards compatible.

For the most part, other JavaScript frameworks are not even in the same class as these four — many just aren’t well-maintained enough to rely on. Deciding between these four can be tough, given that they do offer many similar features. However, considering the communities and resources around each framework may help you come to a conclusion without having to rewrite your web applications four times over.

Node.js Tackles Model and Controller

While Node.js cannot be compared to most JavaScript front end or browser frameworks, it is excluded only because Node.js is really in a league of its own — Node.js is a cross-platform runtime environment, instead of a framework and is meant for use on the server. Node.js represents a bit of a revolution: where once you might only see JavaScript in client-side code (like with any of the JavaScript frameworks above), you can now use JavaScript across both your server and client code bases. You can create a web application entirely in JavaScript, where you previously would have needed both JavaScript and another language, such as Python or Ruby. Since its creation in 2009 by Ryan Dahl and other developers then working at Joyent, Node.js has seen adoption by companies ranging from IBM to Groupon. Both enterprise-level organizations and startups love the flexibility of using JavaScript to build scalable, web-based applications.

With Node.js, a programmer can use JavaScript across all three components of the MVC. Your model may run on your server, and your view may run in the browser, but they can both be written in JavaScript. Just that level of simplification may have guaranteed the rise of Node.js

Node.js’s rapid adoption rate created a boom in related tools. The number of Node.js frameworks you might consider working with seems to grow longer every day. The right frameworks can dramatically improve the process of building a new web application, especially if you are sticking with a well-established design pattern like MVC. These five Node.js frameworks are among the best currently available:

  1. Express: This framework is one of the most popular available in the Node.js ecosystem. Express is both minimal and flexible, but can handle surprisingly large projects. The framework’s creators worked hard to provide fundamental web application features without changing underlying Node.js features.

  2. Hapi.js: As a framework, Hapi.js is fully-featured, especially when you take into account the many plug-ins that Hapi fans have created. This framework’s creators focused on reliability and stability.

  3. Sails.js: Meant for enterprise-grade apps, Sails.js scales well. One of the biggest benefits of using this framework is its powerful data access layer, which lets you get a lot more out of any database you choose to work with.

  4. Mojito: As one of Yahoo’s Cocktails (as the company calls its mobile application development platform based on open web standards), Mojito has more resources than many other frameworks. It is a robust option for mobile applications.

  5. Koa: Created by the same team as Express, Koa is perhaps the next step in where Node.js can go. The framework uses generators to improve error handling, as well as ditches middleware, to create a fast and scalable experience.

Finding exactly the perfect Node.js framework for a project may require a little experimentation, but these frameworks are all maintained with a certain level of documentation, making it possible to dive in and quickly try out your different options.

The Continuing Evolution of MVC and Isomorphic JavaScript

While the concept of MVC first evolved for desktop applications, the pattern has been adapted as a key approach for web-based applications. Even today, many common MVC frameworks, such as Ruby on Rails, put most of the burden of the model, view, and controller logic on the server. However, modern web applications have evolved to take advantage of maturing client technologies, allowing new frameworks to handle more of the MVC logic on the client. The result is isomorphic JavaScript, an approach that enables you to use MVC patterns across both the client and the server.

Simply put, isomorphic JavaScript is rendered on both the server and the client: the back end and the front end of an application run the same code. When a visitor reaches a web-based application using isomorphic JavaScript, the following occurs:

  1. HTML is rendered from JavaScript application on the server

  2. The browser loads with full HTML

  3. JavaScript loads, and then bootstraps, the application

Isomorphic JavaScript opens up some unusual opportunities though you should remember that not everything will render particularly well from the server. Are you dealing with a great deal of data while generating HTML for your application? You’ll want to stick with sending a limited initial query to the server and then fetch everything else with an AJAX call.

With that caveat, though, isomorphic JavaScript offers valuable improvements:

  • Perceived faster load times (due to the time many popular JavaScript frameworks require to render into the DOM)

  • Improved visibility of your application data for search engine indexing

  • Normalized functionality of your web application even for users who have JavaScript turned off

  • Dramatically reduced code maintenance (given that you can use the same code base for both client and server, you have less code to maintain)

Not all Node.js frameworks rely on MVC as a design pattern, nor is doing so necessary to implement isomorphic JavaScript. However, using a familiar design pattern makes for an easier entry into these concepts.

Beyond the Box: Redis transaction correlation for Node.js

Looking at your nodes

The AppDynamics Pro product has boasted an agent for instrumenting Node.js application components for several releases now, which is providing many customers with end to end transaction visibility across their applications incorporating Node.js tiers, as well as – uniquely – method level drill-down into the javascript code itself.

Slide1.png

In common with the other AppDynamics application agents, the Node.js agent recognises the arrival of http traffic as starting a transaction and also auto-detects many common exit points (places where the code makes requests of downstream systems) out of the box, including outbound http calls, queries on various databases and accesses to the memcached and redis caches.

As caches go, however, redis is a slightly unusual beast in that in addition to storing name.value pairs of data in memory for fast access, it also provides message broker functionality, allowing application processes to interact via publish/subscribe messaging.  I recently came across a customer who was using redis to pass requests (and return responses) between services implemented in Node.  To illustrate this, I have a sample app showing this communication between 2 simple simple services.

The app either runs as the http entry point for requests (“node example.js -entry”) or as a service (“node example.js -service”)  (for those readers wanting to follow along with the javascript action at home, the sources are available here)

When these 2 commands are run, the out of the box instrumentation yields the following flowmap:

Unfortunately, this does not look anything like the request/response interaction between 2 application tiers that we know is really going on under the hood. We only see the entry tier of the application, apparently accessing a Redis cache.

The service tier is missing entirely since only tiers executing transactions appear on the flowmap and we do not recognise the arrival of a message on the Redis bus as constituting a transaction entry point and the sending of a message over the Redis bus appears as a cache access since that is the only Redis use-case supported by the out of the box instrumentation.

Fortunately, the Node.js agent provides a java script API we can use to customise the agent’s behaviour.

Fear not, we can customise it!

In order to follow the transaction flow through this Node application, we are going to need to do a couple of things:

  • Recognise calls to the redis message bus as exits
  • tag-and-follow the pub/sub messages that flow through Redis, to facilitate end to end correlation of the transaction flow
  • Recognise the arrival of messages arriving from the Redis bus as starting a transaction

Given that I wrote, and you are reading, this article it will not surprise you to know that the AppDynamics Node agent API provides for all three of these eventualities.

Recognising the calls to the Redis message bus

To do this, we will need to suppress the out of the box identification of the Redis exit, and then create our own custom exit point.

Suppressing the out of the box handling requires us to implement the beforeExitCall callback.  If our callback does not return anything, the default handling of the exit is suppressed.  We do this conditionally for Redis exits to avoid impacting other exits which we may want:

Note we also had to add a call to the startTransaction API in order that we could interact with the agent’s view of the http transaction, which the out of the box HTTP entry support started for us.

Now we have suppressed the out of the box exit handling for Redis, we need to add the code to establish our custom redis exit:

Where the original code simply includes a call to its publish function, the AppDynamics instrumented version surrounds this code with calls to startExitCall and endExitCall to delimit the call itself.

Tagging and following transactions

AppDynamics tags and follows transactions by adding a correlation string to the payload.  Depending on the protocol, this can be added in the message header or the message payload itself.

Since Redis publish / subscribe simply delivers a payload with no bus-level headers we can use, we will transport the correlation string as a field in the JSON payload.

The correlation string, obtained via a call to createCorrelationInfo, is added to the JSON message payload in the ci field.

Note that since this example only contains one client tier and one service tier we can directly correlate the tiers in the call, which means the identifying properties we passed to the startExitCall call will be mapped by ApDynamics to a single destination tier.

If, as is entirely possible in a pub/sub messaging model, the message could arrive at multiple destinations the optional doNotResolve flag should be set on the createCorrelationInfo call, which tells AppDynamics to expect a 1:many interaction between the single client (producer) and multiple consumers and suppress this mapping.

Recognising Redis pub/sub message arrival

The final piece of the jigsaw is detecting the arrival of messages across Redis and causing this to start a continuing segment of the transaction (the sample does this twice, once for the arrival of the request at the service and again to handle correlation of the reply from the service before the http response is written)

Unsurprisingly, the startTransaction API is used to start the transaction.  Since it is a continuing transaction segment, this needs to process the incoming correlation string, which is obtained through the parseCorrelationInfo API, which is simply passed the string from the incoming payload.

Of course, you also see the reappearance of the code to suppress the default Redis exit handling and the dispatch of the service reply message through the Redis bus wrapped as an exit.

Putting it all together

Putting all the above into practise in the application code yields the following flowmap, which looks like we would expect, given our understanding of the workload:

Job done!

I hope I have shown you how flexible the Node agent is in terms of being able to accommodate scenarios that don’t work out of the box.

In conclusion… Rest assured; even if your application flowmap doesn’t appear out of the box “by magic”, never fear…  AppDynamics has the flexibility and simplicity to get the job done easily!

Top 5 Performance Metrics for Node.js Applications

The last couple articles presented an introduction to Application Performance Management (APM) and identified the challenges in effectively implementing an APM strategy. This article builds on these topics by reviewing five of the top performance metrics to capture to assess the health of your enterprise Node.js application.

Specifically this article reviews the following:

  • Business Transactions
  • External Dependencies
  • The Event Loop
  • Memory Leaks
  • Application Topology

Business Transactions

Business Transactions provide insight into real-user behavior: they capture real-time performance that real users are experiencing as they interact with your application. As mentioned in the previous article, measuring the performance of a business transaction involves capturing the response time of a business transaction holistically as well as measuring the response times of its constituent tiers. These response times can then be compared with the baseline that best meets your business needs to determine normalcy.

If you were to measure only a single aspect of your application I would encourage you to measure the behavior of your business transactions. While container metrics can provide a wealth of information and can help you determine when to auto-scale your environment, your business transactions determine the performance of your application. Instead of asking for the CPU usage of your application server you should be asking whether or not your users are able to complete their business transactions and if those business transactions are behaving normally.

As a little background, business transactions are identified by their entry-point, which is the interaction with your application that starts the business transaction. In the case of a Node.js application, this is usually the HTTP request. There may be some exceptions, such as a WebSocket connection, in which case the business transaction could be an interval in your code that is defined by you. In the case of a Node.js worker server, the business transaction could potentially be the job that the Node.js application executes that it picked up from a queue server. Alternatively, you may choose to define multiple entry-points for the same web request based on a URL parameter or for a service call based on the contents of its body. The point is that the business transaction needs to be related to a function that means something to your business.

Once a business transaction is identified, its performance is measured across your entire application ecosystem. The performance of each individual business transaction is evaluated against its baseline to assess normalcy. For example, we might determine that if the response time of the business transaction is slower than two standard deviations from the average response time for this baseline that it is behaving abnormally, as shown in figure 1.

Figure 1 Evaluating BT Response Time Against its Baseline

The baseline used to evaluate the business transaction is evaluated is consistent for the hour in which the business transaction is running, but the business transaction is being refined by each business transaction execution. For example, if you have chosen a baseline that compares business transactions against the average response time for the hour of day and the day of the week, after the current hour is over, all business transactions executed in that hour will be incorporated into the baseline for next week. Through this mechanism an application can evolve over time without requiring the original baseline to be thrown away and rebuilt; you can consider it as a window moving over time.

In summary, business transactions are the most reflective measurement of the user experience so they are the most important metric to capture.

External Dependencies

External dependencies can come in various forms: dependent web services, legacy systems, or databases; external dependencies are systems with which your application interacts. We do not necessarily have control over the code running inside external dependencies, but we often have control over the configuration of those external dependencies, so it is important to know when they are running well and when they are not. Furthermore, we need to be able to differentiate between problems in our application and problems in dependencies.

From a business transaction perspective, we can identify and measure external dependencies as being in their own tiers. Sometimes we need to configure the monitoring solution to identify methods that really wrap external service calls, but for common protocols, such as HTTP, external dependencies can be automatically detected. Similar to business transactions and their constituent application tiers, external dependency behavior should be baselined and response times evaluated against those baselines.

Business transactions provide you with the best holistic view of the performance of your application and can help you triage performance issues, but external dependencies can significantly affect your applications in unexpected ways unless you are watching them.

Your Node.js application may be utilizing a backend database, a caching layer, or possibly even a queue server as it offloads CPU intensive tasks onto worker servers to process in the background. Whatever the backend your Node.js application interfaces with, the latency to these backend services can potentially affect the performance of your Node.js application performance, even if you’re interfacing with them asynchronously. The various types of exit calls may include:

  • SQL databases
  • NoSQL servers
  • Internal web-services
  • External third-party web-service APIs

However your Node.js application communicates with third-party applications, internal or external, the latency in waiting for the response can potentially impact the performance of your application and your customer experience. Measuring and optimizing the response time if your communications can help solve for these bottlenecks.

The Event Loop

In order to understand what metrics to collect surrounding the event loop behavior, it helps to first understand what the event loop actually is and how it can potentially impact your application performance. For illustrative purposes, you may think of the event loop as an infinite loop executing code in a queue. For each iteration within the infinite loop, the event loop executes a block of synchronous code. Node.js – being single-threaded and non-blocking – will then pick up the next block of code, or tick, waiting in the queue as it continue to execute more code. Although it is a non-blocking model, various events that potentially could be considered blocking include:

  • Accessing a file on disk
  • Querying a database
  • Requesting data from a remote webservice

With Javascript (the language of Node.js), you can perform all your I/O operations with the advantage of callbacks. This provides the advantage of the execution stream moving on to execute other code while your I/O is performing in the background. Node.js will execute the code awaiting in the Event Queue, execute it on a thread from the available thread pool, and then move on to the next code in queue. As soon as your code is completed, it then returns and the callback is instructed to execute additional code as it eventually completes the entire transaction.

It is important to note that the execution stream of code within the asynchronous nature of Node.js is not per request, as it may be in other languages such as PHP or Python. In other words, imagine that you have two transactions, X and Y, that were requested by an end-user.

As Node.js begins to execute code from transaction X, it is also executing code from transaction Y and since Node.js is asynchronous, the code from transaction X merges in the queue with code from transaction Y. Code from both transactions are essentially waiting in the queue waiting to be executed simultaneously by the event loop. Thus, if the event loop is blocked by code from transaction X, the slowdown of the execution may impact the performance of transaction Y.

This non-blocking, single-threaded nature of Node.js is the fundamental difference in how code execution may potentially impact all the requests within the queue and how with other languages it does not. Thus, in order to ensure the healthy performance of the event loop, it is critical for a modern Node.js application to monitor the event loop and collect vital metrics surrounding behavior that may impact the performance of your Node.js application.

Memory Leaks

The built-in Garbage Collector (GC) of V8 automatically manages memory so that the developer does not need to. V8 memory management works similar to other programming languages and, similarly, it is also susceptible to memory leaks. Memory leaks are caused when application code reserves memory in the heap and fails to free that memory when it is no longer needed. Over time, a failure to free the reserved memory causes memory usage to rise and thus causes a spike in memory usage on the machine. If you choose to ignore memory leaks, Node.js will eventually throw an error because the process is out of memory and it will shut down.

In order to understand how GC works, you must first understand the difference between live and dead regions of memory. Any object pointed to in memory by V8 is considered a  live object. Root objects – or any object pointed to by a chain of pointers – is considered live. Everything else is considered dead and is targeted for cleanup by the GC cycle.  The V8 GC engine identifies dead regions of memory and attempts to release them so that they’re available again to the operating system.

Upon each V8 Garbage Collection cycle, hypothetically the heap memory usage should be completely flushed out. Unfortunately, some objects persist in memory after the GC cycle and eventually are never cleared. Over time, these objects are considered a “leak” and will continue to grow. Eventually, the memory leak will increase your memory usage and cause your application and server performance to suffer. As you monitor your heap memory usage, you should pay attention to the GC cycle before and after.  Specifically, you should pay attention to a full GC cycle and track the heap usage. If the heap usage is growing over time, this is a strong indication of a possible memory leak. As a general rule, you should be concerned if heap usage grows past a few GC cycles and does not clear up eventually.

Once you’ve identified that a memory leak is occurring, you options are to then collect heap snapshots and understand the difference over time. Specifically, you may be interested in understanding what objects and classes have been steadily growing. Performing a heap dump may be taxing on your application so once a memory leak has been identified, diagnosing the problem is best performed on a pre-production environment so that your production applications are not impacted on performance. Diagnosing memory leaks may prove to be difficult but with the right tools you may be able to both detect a memory leak and eventually diagnose the problem.

Application Topology

The final performance component to measure in this top-5 list is your application topology. Because of the advent of the cloud, applications can now be elastic in nature: your application environment can grow and shrink to meet your user demand. Therefore, it is important to take an inventory of your application topology to determine whether or not your environment is sized optimally. If you have too many virtual server instances then your cloud-hosting cost is going to go up, but if you do not have enough then your business transactions are going to suffer.

It is important to measure two metrics during this assessment:

  • Business Transaction Load
  • Container Performance

Business transactions should be baselined and you should know at any given time the number of servers needed to satisfy your baseline.  If your business transaction load increases unexpectedly, such as to more than two times the standard deviation of normal load then you may want to add additional servers to satisfy those users.

The other metric to measure is the performance of your containers. Specifically you want to determine if any tiers of servers are under duress and, if they are, you may want to add additional servers to that tier. It is important to look at the servers across a tier because an individual server may be under duress due to factors like garbage collection, but if a large percentage of servers in a tier are under duress then it may indicate that the tier cannot support the load it is receiving.

Because your application components can scale individually, it is important to analyze the performance of each application component and adjust your topology accordingly.

Conclusion

This article presented a top-5 list of metrics that you might want to measure when assessing the health of your application. In summary, those top-5 items were:

  • Business Transactions
  • External Dependencies
  • The Event Loop
  • Memory Leaks
  • Application Topology

In the next article we’re going to pull all of the topics in this series together to present the approach that AppDynamics took to implementing its APM strategy. This is not a marketing article, but rather an explanation of why certain decisions and optimizations were made and how they can provide you with a powerful view of the health of a virtual or cloud-based application.

Interested in monitoring your Node.js application performance? Check out a free trial today!

Node.js & io.js Back Together Again

In purely technical terms, io.js is a fork of Node.js—they are both JavaScript runtime environments that streamline the process of developing server-side applications. However, the relationship between these two open source projects is more complex than the term ‘fork’ might imply. The split is a clear lens into the way that many open source projects are managed, and the response communities can have to commercial stewardship.

The separation of the io.js community from Node.js and its subsequent return mark a major change in the question of how open source projects are best run. While these two projects are now merged, understanding the future of Node.js and the governance of open source projects requires a good understanding of io.js’s history.

A Quick History of Node.js

Node.js launched in 2009. Ryan Dahl and other developers working at Joyent invented the framework, leading Joyent to act as a commercial steward for the open source project. The JavaScript community quickly embraced Node.js, especially as new tools (like the npm package manager) arrived. While Node.js was initially created for Linux use, Microsoft worked with Joyent to create a native Windows version of Node.js in 2011.

Ryan Dahl stepped aside as the ‘gatekeeper’ of Node.js in 2012, handing over management duties to a fellow Joyent employee, Isaac Schlueter. Timothy Fontaine (another Joyent employee) took on the same role in 2014. Throughout this time, Joyent effectively held the reins of Node.js, making choices that frustrated some outside contributors. One of the key issues was the sense that Node.js was falling behind.

Joyent’s business model is based on using open source technology across the board. The company offers public and private cloud services, along with consulting and support. When Joyent released its SmartDataCenter and Manta Object Storage platform under open source licenses, the company immediately added to its stewardship responsibilities. Additionally, Joyent also leads the SmartOS open source project. This business model allows Joyent to make certain choices about the management of the various open source projects it controls—choices that those communities might not always choose for themselves. That element of self-interest is controversial at best.

The Dividing Question of Open Governance

In late 2014, Fedor Idutny, a Node.js contributor but not a Joyent employee, started the fork of Node.js that became io.js. Rather than relying on a commercial steward to provide management of the project (and therefore putting that steward in a position to make decisions not supported by the majority of the community), io.js was immediately organized under an open governance structure. A technical committee handled all decisions for the project.

According to an JavaWorld interview with Mikeal Rogers at the time, Idutny, and other Node.js contributors wanted to focus more on building a community around Node.js, rather than following Joyent’s top-down approach. Rogers said, “We’ve been working with Joyent since July to try and move the project to a structure where the contributors and community can step in and effectively solve the problems facing Node [including the lack of active and new contributors and the lack of releases]. My guess is that Fedor was tired of waiting and set io.js up. He didn’t promote it or anything, but those of us who were close enough saw it and jumped on. Then we moved all the Node core-related Node Forward work over, which has been building for some time but can’t do a release due to trademark restrictions.”

The initial members of the technical committee were:

  • Idutny

  • Schlueter

  • Trevor Norris

  • Ben Noordhuis

  • Bert Belder

with Rogers acting as moderator and secretary.

Even during the earliest days of the fork, however, the technical committee discussed an interest in rejoining the core Node.js project, provided Joyent be willing to hand Node.js over to a foundation with open governance.

The Technical Differences Between io.js and Node.js

One of the key issues cited for the fork was Joyent’s failure to push Node.js to stay current with the latest features of the V8 JavaScript engine. io.js was able to move quickly forward to create a more up-to-date tool. The speed at which io.js moved drove serious adoption.

On io.js’ website, the developers behind the project listed their mission as “Bringing ES6 to the Node Community.” The framework did exactly that, building in ES6 functionality almost immediately—winning over a host of users and creating a public sense that Node.js’ slow progress was unacceptable.

In May 2015, Raygun conducted a series of bench-marking tests comparing the then latest versions of both io.js and Node.js. The difference was substantial: there was a 14 percent increase in speed for io.js over Node.js when sending raw JSON responses. io.js had even managed a 5 percent speed increase over their previous release at that point.

The improvements that io.js brought to the table were drastic enough that there was some concern about speeding up a reunification in order to be sure that the two code bases weren’t too different when the time came to merge them.

A Reunification Under a New Organization

In mid-June 2015, the io.js and Node.js communities reintegrated under the leadership of the Linux Foundation. The Node.js Foundation is hosted by the Linux Foundation and has taken ownership of both the Node.js and io.js projects.

The press release issued by the Linux Foundation at the time described the new organization’s structure: “The Node.js Foundation today is also announcing its ratified open governance structure. The open, technical governance model that will guide the project was determined with input from the public, including contributors from both the Node.js and io.js communities. The model includes a Technical Steering Committee that will direct technical decisions, oversee working group projects and manage contributions to the node code base, and a Board of Directors to guide business decisions. The Node.js and io.js Technical Committees are merging to form the Node.js Foundation Technical Steering Committee, demonstrating the formal collaboration these communities will pursue to advance the code bases. Additionally, there will be an individual membership class, which will have representation on the board.”

The current technical steering committee for Node.js contains some familiar names, including Noordhuis, Indutny, Belder, and Norris. The project governance is arranged to offer as much transparency as possible, as well as to require consensus before moving forward. The Node.js Foundation will follow io.js’ lead in publishing regular updates, rather than leaving most information behind closed doors.

Rogers, then listed as the representative of io.js, said in an interview with InfoWorld at the time of the merge, “The goals of Node.js and io.js have never differed. We just had different ideas about how to achieve those goals and we’ve been able to reconcile those ideas into a much stronger merged project now.”

Belder, a contributor to both io.js and Node.js, followed up with an expectation of how the merger would impact day-to-day work: “From now on, the people formerly working on node.js and io.js will be working together again. To a certain extent, this was already the case, but we’ll now have our weekly meetings jointly and make decisions together.” He also added that technical improvements made in io.js would become available in Node.js.

The Future of Node.js and io.js Together

The newest release of Node.js (version 4.0.0) combines both the Node.js and io.js code bases into a single release. The new version essentially retires io.js as a separate code base. Improvements focused on merging in io.js’s advances and include:

  • V8 version 4.5 (the same version of V8 currently shipping with the Chrome web browser)

  • New ES6 features by default (including block scoping, classes, typed, arrays, and template strings)

  • Security improvements

  • Improved platform test coverage

  • Coverage of all major ARM variants

  • Arrow functions (a key feature that was not previously available in io.js)

Node.js v4 also establishes a plan for long-term support and a regular release cycle. The project has also moved to a new GitHub repository.

Node.js’s road map includes several key improvements that will make the framework easier use, including:

  • A debugging and tracing ecosystem

  • Automation tools

  • Improving installation and upgrades

  • Improving stream performance

  • Supporting internationalization and localization

More information about Node.js is available at the project’s website. The website for io.js remains live but has little activity—which ultimately shows the success of the fork. Because io.js existed, the Node.js community has been reinvigorated and has adopted new features. With the retirement of io.js as a separate framework, the developers behind both projects can combine resources and focus on building a lasting community around Node.js.

Furthermore, the existence of io.js drove a crucial conversation about the roles of commercial entities in the open source world. While there are some open source projects where commercial stewards make sense, the nature of open source development requires an open and transparent governance process wherever possible. The ramifications of Joyent handing Node.js over to a foundation will have ripples across the world of software development for years to come.

 

5 Quick Node.js Application Performance Tips

This article series has covered a lot of ground: it presented an overview of application performance management (APM), it identified the challenges in implementing an APM strategy, it proposed a top-5 list of important metrics to measure to assess the health of an enterprise Node.js application, and it presented AppDynamics’ approach to building an APM solution. In this final installment this article provides some tips-and-tricks to help you implement an optimal APM strategy. Specifically, this article addresses the following topics:

  • Business Transaction Optimization

  • Snapshot Tuning

  • Threshold Tuning

  • Tier Management

  • Capturing Contextual Information

1. Business Transaction Optimization

Over and over throughout this article series I have been emphasizing the importance of business transactions to your monitoring solution. To get the most out of your business transaction monitoring, however, you need to do a few things:

  • Properly name your business transactions to match your business functions

  • Properly identify your business transactions

  • Reduce noise by excluding business transactions that you do not care about

AppDynamics will automatically identify business transactions for you and try to name them the best that it can, but depending on how your application is written, these names may or may not be reflective of the business transactions themselves. For example, you may have a business transaction identified as “POST /payment” that equates to your checkout flow. In this case, it is going to be easier for your operations staff, as well as when generating reports that you might share with executives, if business transactions names reflect their business function. So consider renaming this business transaction to “Checkout”.

Next, if you have multiple business transactions that are identified by a single entry-point, take the time to break those into individual business transactions. There are several examples where this might happen, which include the following:

  • URLs that route to the same MVC controller and action

  • Business Transactions that determine their function based on their payload

  • Business Transactions that determine their function based on GET parameters

  • Complex URI paths

If a single entry-point corresponds to multiple business functions then configure the business transactions based on the differentiating criteria. For example, if the body of an HTTP POST has an “operation” element that identifies the operation to perform then break the transaction based on that operation. Or if there is an “execute” action that accepts a “command” URI argument, then break the transaction based on the “command” segment. Finally, URI patterns can vary from application to application, so it is important for you to choose the one that best matches your application. For example, AppDynamics automatically defines business transactions for URIs based on two segments, such as /one/two. For most Node.js MVC frameworks, this automatically routes to the application controller and action. If your application uses one segment or if it uses four segments, then you need to define your business transactions based on your naming convention.

Naming and identifying business transactions is important to ensuring that you’re capturing the correct business functionality, but it is equally important to exclude as much noise as possible. Do you have any business transactions that you really do not care about? For example, is there a web game that checks high scores every couple minutes? Or is there a Node.js CLI cron job that runs every night, takes a long time, but because it is offline and does not impact the end user, you do not care? If so then exclude these transactions so that they do not add noise to your analysis.

2. Snapshot Tuning

As mentioned in the previous article, AppDynamics intelligently captures performance snapshots at a specified interval and by limiting the number of snapshots captured in a performance session. Because both of these values can be tuned, it can benefit you to tune them.

Out-of-the-box, AppDynamics captures the entire process call graph while trimming any granularity below the configured threshold. If you are only interested in “big” performance problems then you may not require granularity as fine as 10 milliseconds. If you were to increase this interval to 50 milliseconds, you will lose granularity. If you are finely tuning your application then you may want 10-millisecond granularity, but if you have no intention of tuning methods that execute in under 50 milliseconds, then why do you need that level of granularity? The point is that you should analyze your requirements and tune accordingly.

Next, observe your production troubleshooting patterns and determine whether or not the number of process snapshots that AppDynamics captures is appropriate for your situation. If you find that, while capturing up 2 snapshots every minute is resulting in too many snapshots, then you can configure AppDynamics to adjust the snapshot intervals. Try configuring AppDynamics to capture up to 1 process snapshot every minute. And if you’re only interested in systemic problems then you can turn down the maximum number of attempts to 5. This will significantly reduce that constant overhead, but at the cost of possibly not capturing a representative snapshot.

3. Threshold Tuning

AppDynamics has designed a generic monitoring solution and, as such, it defaults to alerting to business transactions that are slower than two standard deviations from normal. This works well in most circumstances, but you need to identify how volatile your application response times are to determine whether or not this is the best configuration for your business needs.

AppDynamics defines three types of thresholds against which business transactions are evaluated with their baselines:

  • Standard Deviation: compares the response time of a business transaction against a number of standard deviations from its baseline

  • Percentage: compares the response time of a business transaction against a percentage of difference from baseline

  • Static SLAs: compares the response time of a business transaction against a static value, such as 2 seconds

If your application response times are volatile, then the default threshold of two standard deviations might result in too many false alerts. In this case you might want to increase this to more standard deviations or even switch to another strategy. If your application response times have low volatility then you might want to decrease your thresholds to alert you to problems sooner.  Furthermore, if you have services or APIs that you provide to users that have specific SLAs then you should setup a static SLA value for that business transaction. AppDynamics provides you with the flexibility of defining alerting rules generally or on individual business transactions.

You need to analyze your application behavior and configure the alerting engine accordingly.

4. Tier Management

I’ve described how AppDynamics captures baselines for business transactions, but it also captures baselines for business transactions across tiers. For example, if your business transaction calls a rules engine service tier then AppDynamics will capture the number of calls and the average response time for that tier as a contributor to the business transaction baseline. Therefore, you want to ensure that all of your tiers are clearly identified.

Out of the box, AppDynamics identifies tiers across common protocols, such as HTTP, JMS, JDBC, and so forth. For example, if it sees you make a database call then it assumes that there is a database and allocates the time spent in the method call to the database. This is important because you don’t want to think that you have a very slow “save” method in a ORM class, instead you want to know how long it takes to persist your object to the database and attribute that time to the database.

AppDynamics does a good job of identifying tiers that follow common protocols, but there are times when you’re communication with a back-end system does not use a common protocol. For example, I was working at an insurance company that used an AS/400 for quoting. We leveraged a library that used a proprietary socket protocol to make a connection to the server. Obviously AppDynamics would know nothing about that socket connection and how it was being used, so the answer to our problem was to identify the method call that makes the connection to the AS/400 and identify it as a custom back-end resource.  When you do this, AppDynamics treats that method call as a tier and counts the number of calls and captures the average response time of that method execution.

You might be able to use the out of the box functionality, but if you have special requirements then AppDynamics provides a mechanism that allows you to manually define your application tiers by using the Node.js API functions to further tailor your application.

5. Capturing Contextual Information

When performance problems occur, they are sometimes limited to a specific browser or mobile device, or they may only occur based on input associated with a request. If the problem is not systemic (across all of your servers), then how do you identify the subset of requests that are causing the problem?

The answer is that you need to capture context-specific information in your snapshots so that you can look for commonalities. These might include:

  • HTTP headers, such as browser type (user-agent), cookies, or referrer

  • HTTP GET parameter values

  • Method parameter values

  • Application variables and their values

Think about all of the pieces of information that you might need to troubleshoot and isolate a subset of poor performing Node.js transactions. For example, if you capture the User-Agent HTTP header then you can know the browser that the user was using to execute your business transaction. If your HTTP request accepts GET parameters, such as a search string, then you might want to see the value of one or more of those parameters, e.g. what was the user searching for? Additionally, if you have code-level understanding about how your application works, you might want to see the values of specific method parameters.

AppDynamics can be configured to capture contextual information and add it to snapshots, which can include all of the aforementioned types of values. The process can be summarized as follow:

  1. AppDynamics observes that a business transaction is running slow

  2. It triggers the capture of a session of snapshots

  3. On each snapshot, it captures the contextual information that you requested and associates it with the snapshot

The result is that when you find a snapshot illustrating the problem, you can review this contextual information to see if it provides you with more diagnostic information.

The only warning is that this comes at a small price: AppDynamics uses code instrumentation to capture the values of methods parameters. In other words, use this functionality where you need to, but use it sparingly.

Conclusion

Application Performance Management (APM) is a challenge that balances the richness of data and the ability to diagnose the root cause of Node.js performance problems with minimum overhead required to capture that data. There are configuration options and tuning capabilities that you can employ to provide you with the information you need while minimizing the amount of overhead on your application. This article reviewed a few core tips and tricks that anyone implementing an APM strategy should consider. Specifically it presented recommendations about the following:

  • Business Transaction Optimization

  • Snapshot Tuning

  • Threshold Tuning

  • Tier Management

  • Capturing Contextual Information

APM is not easy, but tools like AppDynamics make it easy for you to capture the information you need while reducing the impact to your production applications.

Want to improve your Node.js application performance? Check out a free trial of AppDynamics today

Understanding Node.js Memory Leaks

Memory leaks can be a serious problem in Node.js, potentially affecting the performance of your Node apps. Although it might look like a predicament in the back-end is causing the application to fail, the real source of a bug could be a Node.js memory leak. It’s important to understand what memory leaks are, why they occur, and how to detect and solve memory leaks in Node.js, to get ultimately to the bottom of fixing memory leaks.

What Is a Memory Leak?

A memory leak occurs when an application takes over part of a computer’s memory and fails to release it at the appropriate time. Over time, this can lead to the computer running out of memory, causing a decrease in performance. When a Node.js memory leak occurs, the affected application may run slowly or freeze completely. A memory leak can cause a serious performance problem that needs to be diagnosed and solved.

How Does Node.js Manage Memory?

Complications with the V8 garbage collector (Google’s Javascript engine) potentially lead to Node.js memory leaks. V8 is an open source engine that runs Node.js applications, although it was not designed specifically for Node. V8 deals with memory management on behalf of the Node.js applications, making life easier for Node developers because it takes away the manual task of writing code that deals with the management of memory. However, automatic memory management can also be a problem because it takes control away from application developers.

When V8 needs to allocate memory to an object in a Node.js application, it usually does so by using a pointer to assign an object or variable to a new piece of memory. Eventually, the available memory starts to run out, at which point V8 begins a process of garbage collection to free up memory.

The V8 garbage collector must identify which regions of memory can be reallocated without affecting the performance of the application. It follows pointers to find out which objects are currently live and which can not be reached by the existing set of pointers. Memory that contains unreachable objects is called a “dead” region, and can safely be reallocated.

What Causes Memory Leaks?

To avoid memory leaks, V8 needs to know the exact locations of all objects in memory. If objects are identified incorrectly as pointers, memory leaks can result. Memory leaks can occur when the actual memory used by an object extends beyond the memory that has been allocated to that object.

Another potential cause of memory leaks is a callback function, a Javascript function that can be passed as an argument to other code. The V8 garbage collector does not always know whether it is safe to remove objects used in a callback function that can be called multiple times, leading to memory not being reallocated when it should. Callback functions are examples of closures, functions that have access to the variables of the function that called it. Closures are a well-known cause of memory problems because the variables must be left in the memory for as long as closure functions could need to use them.

Node.js memory leaks most commonly occur in objects that contain large collections of data, such as arrays or hashmaps. However, Node.js memory leaks can also occur in other object types, such as strings.

Sometimes, the cause of a memory leak in a Node.js application is not in the application’s code, but rather in an upstream code that the application depends on for its execution. This makes Node.js memory leaks difficult to diagnose. If you have been staring at your Javascript code for ages, and you are convinced that it is not causing your memory leak, then consider looking at the upstream code for the source of your problem.

In summary, you should consider the following potential causes of a Node.js memory leak:

  • Callbacks and closures
  • Leaky constructors of classes you have defined
  • Collection objects, such as arrays and hashmaps
  • Upstream code

What Are the Symptoms of a Memory Leak in a Node.js Application?

Memory leaks can affect the performance of Node.js applications, causing them to run slowly, malfunction or freeze up completely. Many leaks begin very slowly, but over time, they can cause the app to slow down as V8 needs to spend more and more time in garbage collection mode to manage the app’s memory uses.

Memory leaks can also cause odd behavior in a Node.js application. For example, you might notice that your application stops being able to open new database connections. This occurs because the leaking code is hanging onto references to the resources that the app needs to open new connections. You may find that you need to restart the app to restore its performance.

Not all memory leaks cause noticeable symptoms during the development or testing phase. However, it is still worth trying to find memory leaks in your application so you can eliminate them. As your app becomes more popular, the greater the number of users that will make demands from it. Even a relatively slow memory leak can damage the performance of an app, slowing it down and preventing it from offering the best possible performance to your users. If you let a memory leak continue unchecked, your app will eventually crash, which can be extremely embarrassing and damaging to your reputation among your customers and the online community at large.

Making more RAM available for your app or restarting your service every time its memory usage starts to get out of hand can prevent a crisis. However, it is better to track down the problem and fix it, so your app runs efficiently and consistently without the constant need for you to monitor it or worry about it breaking down.

How Do You Diagnose a Memory Leak in a Node.js Application?

Many metrics can diagnose memory leaks in a Node.js application. These include heap usage, heap growth and frequency of garbage collection. You can also use tools to help you detect leaks in Node.js applications, some of which are listed in this summary from Mozilla.

A heap profiler is an extremely useful tool for diagnosing memory leaks in Node applications. A non-leaky memory profile shows memory usage increasing in response to incoming requests. After the requests are dealt with, you should see memory usage decrease as objects that are no longer needed are destroyed, and the used memory is released.

A leaky memory profile looks very different from a normal profile. Memory usage increases over time. The longer the application is open, the less memory is available, until you reach the point where you must restart the app to reduce the memory usage to normal and restore the app’s performance. Note that memory leaks can be rapid, in which case they are quick and easy to notice in the heap memory usage, or slow, in which case memory usage increases much more gradually.

Taking a look at the instance counts of various types of objects can help to pin down the source of the memory leak in a Node.js application. If the instance count of a particular type of object grows strongly and does not come back down, then this type of object is likely to be the source of the memory leak. Usually, you would expect instance counts of each object to come back down after each garbage collection cycle, so look for objects that don’t have this behavior.

Analyzing these metrics can help you work out which part of your code is causing the problem so you can track down the bug and fix it as quickly as possible. For example, if you have written a leaky class called myClass, then you are likely to see objects of type myClass using up most of the memory in the heap stack. You can then check your definition of the myClass class to look for code that allows a memory leak to occur.

Also, pay attention to the frequency with which the V8 engine runs the garbage collection. When this happens, you might notice your app slowing down. The leakier your code, the more often V8 needs to perform garbage collection.

Dealing With Node.js Memory Leaks

It is important to diagnose and control memory leaks while developing your Node application. Be aware that your application might be experiencing memory leaks from more than one source, so when you think you have eliminated a memory leak, repeat your tests to make sure that the leaks are gone.

Although diagnosing and eliminating memory leaks takes some time, it is worth making the effort to wipe out leaks while developing your app. If you try to build on a leaky code to add more functionality to your app later on, you may find that its performance becomes too detrimental for the app to be useful to your users.

By learning to deal with Node.js memory leaks, you can train yourself to build better apps that work well. You’ll learn to consider the possibility of memory leaks when writing new code. For example, when creating a new class, you need to watch out for constructors that create large objects that don’t get deleted when they should be. You can help to prevent Node.js memory leaks by always considering how and when objects will be created and destroyed while you write your code.