Use Cases
We will continue to add to this list, so keep checking back! If there’s a use case you would like to see, let us know!
1) Do You Make Assumptions About the Cause of Performance Issues?
The Problem:
Company A notices that one of their servers is using far more memory than usual, which is making their website run slowly. This particular server has two systems running on it – the streamer (which gathers data) and the aggregator (which summarizes the collected data). The CTO is convinced that the streamer is causing the problem, and wants to move the streamer to its own server loaded with memory. Before they spend the money on a new server, how can Company A figure out for sure which system is causing the memory problem?
The AppFirst Solution:
Using AppFirst’s Administration tool, Company A has divided the server into two components and labeled them as the applications “Streamer” and “Aggregator.” This is awesome, because it means they can look at the data for the streamer and aggregator and compare them over the last week or so to see what’s changed.
First, they look at the streamer and are surprised to find that it’s only been using 614MB of memory – that’s not much at all! When they look at the aggregator data, however, they find that the aggregator’s memory usage has been increasing over the last few days and is currently at 1649MB. Over the last 24 hours, there are gaps in the Data Insight graph, indicating that the aggregator actually stopped running a few times because it didn’t have enough memory. Yikes!
Company A moves quickly to resolve the problem, adding an additional 6GB of memory to the server. They check in later and see that the server is running steadily, using about 4GB of memory, and the aggregator is using about 2.5GB of that. The server was originally running on 2GB of memory total. That means that if Company A had bought a new server and moved the streamer, there still wouldn’t have been enough memory for the aggregator to run! Good thing they didn’t spend that money!
2) Do you get noisy, unhelpful alerts?
The Problem:
The IT Ops person at Company B suspects that there may be a memory leak on one of their servers. However, an extra load was recently put on this server, so it’s hard to tell whether the increased memory usage is because of that or because of a leak. Company B is getting a lot of alerts about memory usage on the server, but how can they tell if it’s actually something they need to look into?
The AppFirst Solution:
Using AppFirst’s Administration tool, Company B can divide their servers into components, then label these components as applications. Now, instead of just setting an alert on an entire server, they can set an alert on a specific component of the server. When the alert email arrives, they won’t have to hunt around to find the problem – the email notification will show them exactly where it is.
So now The IT Ops person gets an alert saying that the memory usage for the application “Aggregators” has crossed the threshold that was set. But wait, back up. How did they know what value to choose for the alert threshold? Using AppFirst’s state of the art alerting system, Company B was able to select a reasonable threshold using that application’s recent memory usage data.
Clicking on the link in the email takes Company B to the Data Insight graph for “Aggregators,” where they can see that memory usage has been steadily increasing, both before and after the extra load was added. That looks like a memory leak! Luckily, the IT Ops person can send the developers a snapshot of the Data Insight graph, so the developers can get to work on solving the problem.
Turns out it was a memory leak, and the developers are able to fix the problem. Yay! But wouldn’t they like to double check to make sure it’s completely fixed? The developers can confirm by using AppFirst on their QA machine to look at the data and make sure there’s no memory leak before rolling to production. Looking at the current data, they can see that memory usage remains steady and only increases when an extra load is put on the server. All fixed, and Company B’s customers never even knew there was a problem!
