The StrongOps Console shows you real-time performance metrics for your Node.js product. Our console lets you view average response time by tier (e.g. HTTP, MongoDB, etc), slow endpoints and database queries, CPU usage, the number of concurrent connections, memory usage, Node.js event loop time, and sent and received message to and from the MQ server (supported via strong-mq). Let’s take a look at each of these individual graphs on the console and show how you can best utilize each of them.
Average Response Time by Tier
Average Response Time gives you a bird’s eye view of how your system is performing. Each metric shows the average response time in the last minute for that part of your system (and overall for HTTP). You can see at a glance how each of your databases are performing, plus see outgoing HTTP requests (for example, Facebook, Twitter, other external API). These are shown as a stacked area so you can quickly determine which components are contributing to performance at any given point.
This graph presents data for MySQL, Memcached, Redis, and MongoDB queries, as well as HTTP responses. You can highlight or hide either of these as desired, allowing you to focus on them individually or in combinations. The ‘http’ line shows the average total time for any incoming HTTP request. The more complex your page is, the longer this total time might be.
When testing your product’s average response time, you will see what is happening with your product, but you may not know why. There may be exceptions, or there may be spikes that will affect your product regularly. Knowing which it is requires a familiarity with your product and how changes or activity affects it. Test and analyze the individual transactions to see how they influence things. Which transactions caused an increase in response time? Which barely impacted response time? And which are critical to your product?
Slow Endpoints and Databases
As the turtle icon suggests, the slow endpoints graph will display where your product may be getting bogged down. These are specific HTTP requests served or database calls that performed slower than others. You’ll use this to see exactly what an API is doing when it is behaving slowly.
You can hover over HTTP requests for details and you can drill down to see what percentage of the request was spent on each database query. You can also drill down for a detailed Path Map of which queries depended on which.
Knowing why your functions are slow is a significant part of the battle. Each top function includes a breakdown showing where your time is spent. By knowing where your servers’ resources are going, you can isolate and optimize the slowest parts of your application.
This graph shows you the time this process has spent user and system space.
You can highlight or hide user or system details.
You can use this chart to determine if your process is CPU intensive. If it is, you may want to consider scaling out so you can share this load on multiple CPU cores or even multiple servers. Node.js is single threaded so CPU intensive tasks can block the event loop and cause poor performance for your application.
Currently StrongOps monitors on a per-process basis as well as summary data for all the processes in your app. You have the option to drill down to the process level stats.
The “Connections” graph shows the number of connections you have established, as well as an average throughput. Considerations for your product will include how many people will be using your product at the same time, what they will be doing while connected and how much data might be moved in either direction, and how long they will be connected. Again, it means being aware of what your product needs to do.
A metric showing many people are actively using your product at any given moment can be good for tuning your product as well as for understanding other metrics. If you your Concurrent Connections go up you can expect your heap size to increase as well.
You can highlight or hide Concurrent Connections and Throughput.
This graph will display heap (current heap size), RSS (resident set size) and V8 GC (heap size sampled immediately after a full garbage collection). As with our other graphs, you can customize what you see by highlighting or hiding any of these three sets of data.
Heap size is the designated amount of virtual memory being used, while RSS is the portion of physical RAM being used from the process’s memory.
Our event loop metric is measuring the time from calling nextTick to when the function is executed. This can be different from app to app but we’ve set a default threshold of 10ms (configurable). Any wait longer than that will register as a ‘blocked’ event loop. We measure this by how often the threshold is reached and by how much. We chart the average time taken by the eventloop and the slowest eventloop for that minute.
The key to remember is that since Node.js can only do one thing at once, the amount of requests your product gets will impact your Event Loop and efficiency. Node.js needs a fast event loop to be able to deliver those lightning-fast speeds you’re looking for.
If you’re using strong-mq you’ll see the incoming and outgoing messages in this chart. Strong-mq supports many common mq protocols and libraries. For more information go here: http://docs.strongloop.com/strong-mq
Clustered Application Data
We are now aggregating the data for all the processes in your applications. No more sifting through an endless process list. You’ll see the aggregated statistics for all processes in the dashboard, with the continued ability to drill down to an individual processes using the filters on the left.
The profiler dashboard now provides an easy way to get detailed CPU data for an individual process. The CPU profiler runs the V8 profiler on a particular process that has the strong-agent instrumentation. Select your app, your pid, start it when you think there’s some cpu data you need to get details on, then stop it. You don’t need it running more than a short time; 4-10 seconds is usually enough to see what’s going on.
Once you have some profile data, you can filter out the noise in a few steps. First, you’ll want to tweak what percent of the time actions have to take to be relevant and hiding the shorter bits. Then you can collapse branches of the call stack tree that only contain a single action to focus directly on where real branching occurs and where the majority of the time in a branch is spent. You can also specify whether or not to include descendant time at each level, allowing you to see the time spent at each level of a branch.
Some notes about the graph:
– (program) is time V8 spends in native code (often idle time)
– (root) is the time spent in your node.js application code
With any of these graphs, we encourage you to use the real-time insight into capacity utilization and instantly see how changing usage affects performance. That is, as you develop and change your code and product, see how its performance is affected. By seeing what your app is talking to you can see what might be slowing it down. This is especially critical in production but also valuable if something goes wrong with your product and you need to fix or improve how your app functions. And you can make it easier by configuring alerts for the graphed values or by adding subusers to your monitoring team.
We’re not done with the StrongOps console. We are already hard at work adding more features to StrongOps to make monitoring your product easier, included Enhanced Memory Profiling, Memory Leak Detection, Garbage Collection Monitoring, a Live Error Detector, Build and Deploy Service, Baselining and Anomaly detection. We’ll announce more details as we get closer to releasing these new features. And if you are interested in learning more about our roadmap or providing feedback and suggestions about the console to our product manager, write us at firstname.lastname@example.org and let us know. We value your opinions about where StrongOps should go from here.
There are many ways to utilize the StrongOps console, but it is your familiarity with your product that allows you to make the most of the real-time data the console provides. Monitoring doesn’t necessarily mean you will get information that you can put to use immediately, but it can help you compile good intel to help shape your product and know what is happening as you go into production as well as assist if something goes wrong.
We’re hoping our feedback provides some new ideas as to how to make the most of our dashboard metrics. But we know we have incredible users who already put our dashboard to use in very productive ways. StrongOps users – if you have tips and tricks that you would like to share, don’t hesitate to write us at email@example.com so we can spread the word.
- What’s in the upcoming Node v0.12 release? Six new features, plus new and breaking APIs.
- Ready to develop APIs in Node.js and get them connected to your data? Check out the Node.js LoopBack framework. We’ve made it easy to get started either locally or on your favorite cloud, with a simple npm install.
- Need for Node? Learn more about both the private and open options StrongLoop offers.