The Cloud Analytics tool helps you do real-time performance analysis of your Node.js™ application.

Cloud Analytics requires Node 0.4.0 or later.

In this page:

Also see New metrics on no.de.

Analytics Display Overview

The analytics tool displays two kinds of charts: line graphs and heat maps.

Line graphs display the quantity that you're measuring at a given time. For instance, if you're measuring the number of HTTP operations by IP address, the chart shows a stacked line graph of the number of requests for each IP address per second.

Heat maps let you see three dimensions of data, much like a rainfall map that uses different colors for the amount of rain in a particular region. Cloud analytics heat maps display colored blocks of different densities. For instance, in a heat map that displays the number of threads broken down by application and CPU runtime, the x-axis shows time in one-second intervals, and the y-axis shows run time. The density of each block, or bucket, in the graph represents the number of threads that took up a particular amount of run time. You can use the filters or click on a bucket to see how many times a thread ran on a processor for that length of time at that time. The height of each bucket gives a range of values along the y-axis.

In both kinds of charts, the x-axis represents time in one-second intervals. The y-axis represents one variable that you're measuring, but the scale changes as the range of values widens or narrows.

Available Metrics

Cloud analytics can show you different kinds of metrics:

• CPU thread executions
• HTTP server operations
• HTTP client operations
• Garbage collection operations
• Socket operations
• Logical file system operations

In most cases, the number of operations is not as interesting as decomposing the operation by latency. Latency is the amount of time between making a request and its fulfillment.

CPU thread executions

This metric can help you understand how your application uses the CPU. It reports the number of thread executions sorted by different criteria. A thread execution starts when when the thread is put on the CPU and ends when it is taken off.

You can use the following decompositions by themselves to get a line graph of the number of thread executions or combine them with runtime to display a heat map.

The line graphs that show the number of executions aren't particularly interesting. The heat maps of run time, which show how long the thread was on the CPU, are more revealing because they show when your application has been doing a lot of computation.

Selecting runtime by itself without an addition decomposition is results in a heat map of thread executions decomposed by runtime that's not particularly useful.

If your application isn't running for very long, you can look at why it's coming off CPU. It might be blocking on a kernel lock (potentially indicating kernel lock contention), a userland lock (indicating user-level lock contention), a condition variable (indicating it's probably waiting for some other event, like disk I/O or networking), and so on. Or it may have been runnable but taken off the CPU because something else of higher priority needed to run.

This is a low-level and subtle metric, but it may help you understand whether the reason an application is taking so long to serve requests is because it's spending a lot of time on the CPU.

HTTP server operations

HTTP server performance is the primary performance metric for a web server.

You can use the following decompositions by themselves to get a line graph of the number of events, or you can combine them with latency to get a heat map.

HTTP client operations

This metric reports HTTP requests and responses that originate from your application as opposed to the ones that it serves. You can use this data to help you determine whether your server's latency is due to the latency of some other web service you're using. For example, if your service stores data on Amazon's S3, you can see how long requests to the S3 web service take.

If you find that another web service is the source of your high latency, then you can investigate that other web service (if you're able to) or rethink how your application uses it, perhaps by caching results where possible.

Garbage collection operations

This metric lets you observe latency bubbles resulting from the JavaScript virtual machine's garbage collector. The garbage collector tracks allocated memory and frees memory that's no longer being used. This means that, as a programmer, you don't need worry about memory allocation and deallocation. However, when the garbage collector is running, all of your application code is suspended.

You can use this metric to observe garbage collection in your application. In this case, "latency" refers to how long the garbage collection operation took. If you see garbage collection activity correlate with HTTP request latency spikes, you may need to rethink how memory is being used in your application to avoid creating so much garbage, or else tune the GC to avoid large spikes.

Socket operations

Socket operations are the basis of HTTP activity, WebSockets, and most other types of network activity. This metric lets you observe activity for non-web applications. Because it's not possible to know which messages correspond with which others, it's impossible to show latency directly at this level.

Logical file system operations

Disk I/O can be a source of significant latency. This metric examines one of the primary causes of disk I/O by applications: accessing the filesystem.

If you see significant latency here that corresponds with HTTP request latency, you might consider changing the way your application interacts with the filesystem, perhaps by prefetching or caching data.

The decompositions help you identify precisely who is doing what so you can optimize the right thing. Unlike the Node.js metrics, this metric examines all filesystem activity in your SmartMachine. The decompositions by process ID and application name are useful in these cases.

Learning More About Cloud Analytics

You can learn more about using heat maps to visualize latency from these resources:

• Visualizing System Latency
• Introduction to Cloud Analytics
• Solving Big Problems with Real-time Visibility into Cloud Performance (video)