AppDynamics Launches Extension BuildPack for Pivotal CloudFoundry Applications

Not long ago, we told you about Pivotal Cloud Foundry (PCF) buildpacks and service brokers, and all the ways you can deploy AppDynamics agents in a PCF environment.

Buildpack is the key concept here. When you do a deployment to PCF, the buildpack is your foundation. You include the app with the buildpack, which incorporates all the logic needed to connect to various PCF services. Because the Cloud Foundry platform includes a mechanism for adding support for third-party services like AppDynamics, it’s really easy to add our APM instrumentation to all your applications without having to make any code changes. We’ve been doing this for some time, of course, and Pivotal recently recognized AppDynamics for our outstanding solutions and services, specifically our support for .NET in the Pivotal environment.

Here’s a new example of how we’re staying on the front edge of PCF development. For the first time, we’re using an innovative Cloud Foundry feature called multi-buildpacks. Starting with v4.5.514 of the AppDynamics Application Monitoring for PCF tile, we’re offering an AppDynamics Extension Buildpack that works in tandem with standard buildpacks using Cloud Foundry’s multi-buildpack workflow.

The .NET team at PCF has been leading the way in multi-buildpack development (more on this in a bit) and we’ve recognized the value of this approach. Now our goal is to apply the same model to AppDynamics’ APM support for all PCF applications.

The Standard Buildpack Model

With a traditional buildpack, we build the logic for integrating AppDynamics agents directly into the official Cloud Foundry community buildpack. We test our code against the main buildpack code, which is maintained by Pivotal on behalf of the Cloud Foundry community. We then send a pull request to Pivotal, which takes our code and releases it as an official part of the buildpack. This is a well-established model carefully managed by Pivotal and adhered to by third-party service providers like AppDynamics. It works because it’s a well-known and understood mechanism. But there’s a better way to do it.

The Advantages of Multi-Buildpack

Pivotal’s multi-buildpack concept is like a layer cake. The main buildpack—the base layer—is the official community buildpack. Third-party providers like AppDynamics provide additional functionality (or layers) on top of the base layer. The end result is a multi-buildpack that can be deployed as essentially a single piece. For example, here’s how we’d push a .NET HWC application with the AppDynamics-specific extension (appdbuildpack) and the base buildpack from Cloud Foundry (hwc_buildpack):

cf push -b appdbuildpack -b hwc_buildpack -s windows2016

This is a good model with many benefits, including a clear separation of responsibilities. Pivotal is responsible for the core buildpack and how it links to the service broker and other parts of the Cloud Foundry platform. It also manages all the services your application needs, such as routing and deployment. Third-party providers like AppDynamics are responsible for how their agent installs. If a third-party service introduces a bug, the glitch won’t break the main buildpack.

From our perspective, another benefit of this model is that it gives AppDynamics more control over what goes inside our buildpack, such as custom configuration for our APM Agents. Suppose, for instance, you want to include a custom configuration definition file or custom logging capabilities. It’s very easy to do so. Our buildpack extension defines a folder where you can include the appropriate custom files when you push the application. Once deployed, the application will have the AppDynamics agent installed with the custom configuration file in place. This eliminates the need to fork a buildpack for the sake of customizing agent behavior.

From the customer’s perspective, the multi-buildpack model provides a strong support system. It’s very clear who they need to work with (e.g., AppDynamics or Pivotal) for help with specific components or services. Another plus is that we bundle this buildpack with the AppDynamics Service Broker tile. So when you install the latest version of our tile, it will automatically install the buildpack in your environment. And when you deploy an application using any of the main language buildpacks, our extension will be applied on top.

AppDynamics and Multi-Buildpack

Our goal isn’t simply to make AppDynamics work on PCF, it’s to make it work in the best way possible. We already have added support for .NET HWC applications and .NET Core to our AppDynamics Extension Buildpack, and we will soon bring this approach to other dynamic language environments as well, including Python, Go and NodeJS. We will also add support for the Java buildpack to do advanced configuration of AppDynamics Java Agents, although we will, of course, continue to support basic configuration in the standard Java buildpack.

See for yourself how the AppDynamics Extension BuildPack (Multi-BuildPack Approach) can make your life easier!

Best Practices for Instrumenting Containers with AppDynamics Agents

In this blog I will show some best practices for instrumenting Docker containers, using docker-compose with a few popular AppDynamics application agent types. The goal here is to avoid rebuilding your application containers in the event of an agent upgrade, or having to hard-code AppDynamics configuration into your container images. In my role as a DevOps engineer working on AppDynamics’ production environments, I use these techniques to simplify our instrumented container deployments. I’ll cover the install of binary agents like the Java agent, as well as agents installed via a repository such as Node.js or Python.

Before getting into the best practices, let’s review the most common deployment pattern—which isn’t a best practice at all.

Common (but not best-practice) Pattern:  Install Agent During Container Image Build

The first approach we’ll cover is installing the agent via Dockerfile as part of the application container build. This has the advantage of following the conventional practice of easily copying in your source files and providing transparency of the build in your Dockerfile, making adoption simpler and more intuitive. AppDynamics does not recommend this approach, however, as it requires a fresh copy of your application image to be rebuilt every time an agent needs an upgrade. This is inefficient and unnecessary because the agent is not a central part of your application code. Additionally, hard-coding the agent install in this manner may prove more difficult when you automate your builds and deployments.

Java Example

In this Dockerfile example for installing the Java agent, we have the binary stored in AWS S3 and simply copy over the agent during build time of the application image.

Dockerfile snippet: Copy from S3

Here is a similar step where we copy the agent locally.

Dockerfile snippet: Copy locally

Node.js Example

In this example, we use npm to install a specific Node.js agent version during build time.

Dockerfile snippet

Python Example

In this example, we use pip to install a specific Python agent version during build time.

Dockerfile snippet

Best Practices Pattern: Install Agents at Runtime Using Environment Variables and Sidecar Container

The below examples cover two different patterns, depending on agent type. For Java and similarly packaged agents, we’ll use something called a “sidecar container” to install the agent at container runtime.  For repository-installed agents like Node.js and Python, we’ll use environment variables and a startup script that will install the agent at container runtime.

Java Example

For the sidecar container pattern, we build a container image with the agent binary that we want to install. We then volume-mount the directory that contains the agent, so our application container can copy the agent during container runtime, and then install. This can be simplified by unpackaging the agent in the sidecar container, volume-mounting the newly unpackaged agent directory, and then having the application container point to the volume-mounted directory and using it as its agent directory. We’ll cover both examples below, starting with how we create the sidecar container or “agent-repo.”

In the Dockerfile example for the Java agent, we store the binary in AWS S3 (in an agent version-specific bucket) and simply copy the agent during build-time. We then unzip the agent, allowing us to either copy the agent to the application container and then unzipping, or simply pointing to the unzipped agent directory. Notice we use a build ARG, which allows for a more automated build using a build script.

Agent Repo Dockerfile: Copy from S3

Here’s the same example as above, but one where we copy the agent locally without using a build ARG.

Agent Repo Dockerfile: Copy locally

The build script utilizes a build ARG. If you’re using the S3 pattern above, this allows you to pass in the agent version you like.

build.sh

Now that we have built our sidecar container image, let’s cover how to build the Java agent container image to utilize this agent deployment pattern.

In the Docker snippet below, we copy in two new scripts, extractAgent.sh and startup.sh. The extractAgent.sh script copies and extracts the agent from the volume-mounted directory, /sharedFiles/, to the application container. The startup.sh script is used as our ENTRYPOINT.  This script will call extractAgent.sh and start the application.

Java Dockerfile snippet

extractAgent.sh

The startup.sh script (below) calls extractAgent.sh, which copies and unzips the agent into the $CATALINA_HOME directory. We then pass in that directory as part of our Java options in the application-startup command.

startup.sh snippet

In the docker-compose.yml, we simply add the agent-repo container with volume mount. Our Tomcat container references the agent-repo container and volume, but also uses agent-dependent environment variables so that we don’t have to edit any configuration files. This makes the deployment much more automated and portable/reusable.

docker-compose.yml

In the example below, we show another way to do this. We skip the entire process of adding the extractAgent.sh and startup.sh scripts, electing instead to copy a customized catalina.sh script and using that as our CMD. This pattern still uses the agent-repo sidecar container, but points to the volume-mounted, unzipped agent directory as part of the $CATALINA_OPTS.

Java Dockerfile snippet

catalina.sh snippet

OK, that covers the sidecar container agent deployment pattern. So what about agents that utilize a repository to install an agent? How do we automate that process so we don’t have to rebuild our application container image every time we want to upgrade our agents to a specific version? The answer is quite simple and similar to the examples above. We add a startup.sh script, which is used as our ENTRYPOINT, and then use environment variables set in the docker-compose.yml to install the specific version of our agent.

Node.js Example

Dockerfile snippet

In our index.js that is copied in (not shown in the above Dockerfile snippet), we reference our agent-dependent environment variables, which are set in the docker-compose.yml.

index.js snippet

In the startup.sh script, we use npm to install the agent. The version installed will depend on whether we specifically set the $AGENT_VERSION variable in the docker-compose.yml. If set, the version set in the variable will get installed. If not, the latest version will be installed.

startup.sh

In the docker-compose.yml, we set the $AGENT_VERSION to the agent version we want npm to install. We also set our agent-dependent environment variables, allowing us to avoid hard-coding these values. This makes the deployment much more automated and portable/reusable.

docker-compose.yml

Python Example

This example is very similar to the Node.js example, except that we are using pip to install our agent.

Dockerfile snippet

In the startup.sh script, we use pip to install the agent. The version installed will depend on whether we specifically set the $AGENT_VERSION variable in the docker-compose.yml. If set, the version set in the variable will get installed. If not, the latest version will be installed.

startup.sh

In the docker-compose.yml, we set the $AGENT_VERSION to the agent version we want pip to install. We also set our agent-dependent environment variables, allowing us to avoid hard-coding these values. This makes the deployment much more automated and portable/reusable.

docker-compose.yml

 

Pick the Best Pattern

There are many ways to instrument your Docker containers with AppDynamics agents.  We have covered a few patterns and shown what works well for my team when managing a large Docker environment.

In the Common Pattern (but not best-practice) example, I showed how you must rebuild your application container every time you want to upgrade the agent version—not an ideal approach.

But with the Best Practices Pattern, you decouple the agent specifics from the application container images, and direct that responsibility to the sidecar container and the docker-compose environment variables.

Automation, whenever possible, is always a worthy goal. Following the Best Practices Pattern will allow you to improve script deployments, leverage version control and configuration management, and plug them all into CI/CD pipelines.

For in-depth information on related techniques, read these AppDynamics blogs:

Deploying AppDynamics Agents to OpenShift Using Init Containers

The AppD Approach: Composing Docker Containers for Monitoring

The AppD Approach: Leveraging Docker Store Images with Built-In AppDynamics

 

 

How to Optimize Enterprise-Scale Node.js Applications

Node.js is rapidly becoming one of the most popular platforms for building fast, scalable web and mobile applications. In fact, the 2017 Node.js User Survey reveals that there are currently over 7 million Node.js instances online, with three in four users planning to increase their use of Node.js in the next 12 months. And it’s easy to see why: 68 percent of those users say Node.js improves developer productivity, 58 report it reduces development costs, and 50 percent say it increases application performance.

As Node.js increasingly becomes the preferred technology for application development, the demand for expert Node.js developers will also continue to increase. But while plenty has been written about what Node.js can do, how developers can get started using it, and why it has become a core server-side technology with some of the world’s biggest corporations—there’s not much that’s been written to help beginner or intermediate Node.js developers take their skills to the next level. Until now.

In our latest eBook, Advanced Node.js: Optimize, Deploy, and Maintain an Enterprise-Scale Node.js Application, we share advanced techniques for launching and running an enterprise-scale product, service, or brand built on Node.js.

This is a topic that has not, in our opinion, gotten the attention and expert insights it deserves. In most cases, the post-launch journey is far longer and has a bigger impact than the development process itself. This stage also determines whether a Node.js application will succeed or fail at delivering on the business value the technology promises.

The eBook provides a practical foundation for success during the critical first three months or so of a successful Node.js journey—the time span that covers the period from pre-production planning to continuous deployment and testing.

Specifically, the eBook offers tips, tricks and best practices for each of the following critical points:

1. Preparing for Production Launch

Preparing for a release is always a critical point in any application development journey, and that’s certainly the case for Node.js projects. It’s your team’s final opportunity to find and fix issues before they impact your deployment process, your end users, or the business itself.

The eBook walks users through a pre-release process with the following areas of emphasis:

  • Optimizing Your Code

  • Best Practices for Error Handling

  • Confirming Your Code Meets Security Requirements

  • Configuring for a Production Environment

  • Deployment Considerations

When it comes to code optimization, one of the many pre-production best practices detailed in the eBook is a process called “linting.” This entails running an automated code quality tool—such as ESLint or JShint—through your codebase. It usually covers only very basic quality issues, but that’s the point: It catches avoidable—and usually very easy-to-fix—errors before they put a production application at risk.

2. The First 24 Hours of Your Node.js Deployment

After covering the fundamentals of an effective pre-production workflow, we next look at what to expect and how to respond during the critical first 24 hours after deployment.

Deploying an enterprise application can be harrowing. After all, XebiaLabs’ Application Release Automation Trends survey revealed that up to 30 percent of all application deployments fail. Meanwhile, the Trends in DevOps, Continuous Delivery & Application Release Automation survey revealed that 77 percent of organizations have software production release problems. Clearly, anyone tasked with deploying an application should be ready for things to go wrong—perhaps very wrong.

While a robust pre-production process can help minimize the impact of bugs, configuration failures, and other avoidable problems, expert Node.js developers must know how to address common “Day One” deployment problems—particularly those that result in crashes or other high-impact issues.

Typical problems that may arise within the first 24 hours include:

  • Crashing Node.js Processes

  • Exceeding API Rate Limits

  • Troubleshooting WebSocket Issues

  • Dependency Issues

  • File Upload Issues

  • DDoS Attacks

The good news about these Day One surprises (and there will be surprises) is that you’re going to learn a lot about building better Node.js applications and about deploying your applications with fewer post-deployment issues. While problems can and will continue to happen in the future, truly serious problems will probably be fewer and farther between.

Even better news is that once you effectively troubleshoot these Day One issues, you’ll be dealing with a more stable and reliable application. That, in turn, frees you to focus on ways to improve your application’s performance and to upgrade your own process for building, testing, and deploying Node.js applications.

3. Ongoing Management

Having successfully deployed, the final chapter of the eBook looks at the ongoing management of your Node.js application. While this isn’t too different from any other application rollout, there are a couple of specifics you should watch out for:

  • Memory Leaks

  • Managing Node.js Concurrency

  • Monitoring

As we discuss in the eBook, application performance monitoring (APM) is vital to maintain the stability of your application deployment and to detect subtle regressions that may result in application slow-down or outright failure if left unchecked. An APM solution like AppDynamics can offer end-to-end insight into application behavior and provide specific monitoring capabilities for the Node.js stack.

Get the Guide

Read all the best practices for deploying and managing your Node.js applications in our latest eBook, Advanced Node.js: Optimize, Deploy, and Maintain an Enterprise-Scale Node.js Application.

AppDynamics and NodeSource Team Up For Enterprise Node.js Monitoring

Node.js is a popular choice with application development teams due to its event-driven, non-blocking, flexible, lightweight and extensible framework which enables faster innovation and adoption of microservices. AppDynamics has supported monitoring of Node.js since 2014. It has been a cornerstone of our Unified Monitoring strategy providing visibility into end-to-end transactions, across disparate tiers and programming languages, to provide a full view of a user’s journey through an application.

That is why we are excited to announce our collaboration with NodeSource to provide the best monitoring support for the NodeSource N|Solid runtime. NodeSource is an active contributor to the Node.js community, and the leader in providing enterprises with a stable and certified Node.js runtime. The NodeSource N|Solid runtime tracks and builds off the Node.js LTS (Long Term Support) release and is augmented with performance tuning, management functionality, enhanced security capabilities and deep insights that enable developers to better understand Node.js applications and services.

“NodeSource customers are utilizing N|Solid to power mission critical applications and depend on enterprise-grade solutions to reliably run their businesses,” said Joe McCann, CEO at NodeSource. “Our collaboration with AppDynamics will give customers better visibility into their Node.js applications by offering deeper visibility and additional metrics that are used to resolve issues faster and allow them to spend more time innovating.”

When the AppDynamics Node.js agent is installed on a NodeSource N|Solid runtime, it automatically collects additional metrics provided by N|Solid and makes them available in the AppDynamics controller, making it faster and easier to monitor and diagnose Node.js performance.

 

      

Figure 1. N|Solid Metrics, available from the AppDynamics metric browser, provide additional visibility into event loop activity and other indicators of Node.js process health

Additionally, all of the traditional benefits provided by AppDynamics remain in place such as automated distributed transaction correlation across multiple tiers and instances, process and transaction wide snapshots including database, cache, and NoSQL visibility, and automated performance baselining.

Learn more about AppDynamics support for Node.js and make sure to visit NodeSource to learn more about N|Solid.

 

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!