As the name implies, the Web Performance Lab is all about performance optimization. We felt it was our duty to investigate server-side monitoring as part of our industry. We also needed a monitor that could serve us accurate, reliable data. Read on for a review of our experiences working with New Relic.

What is Server-side Monitoring?

In a nutshell, it is a way for you to watch your web and app servers for performance issues using a monitoring service. The lab’s first go-to was New Relic; a big player in the application performance monitoring arena. The goal was to monitor a smaller version of my scaling Magento project’s test environment.

Monitoring agents are programs that sit on the target server and collect data about the system to send to the monitor controller (New Relic). Once the agent is set up, we will execute a 5,000 VUser test and see how the system performs. This is important because we want to have a Proof of Concept that the load tests are indeed hitting our server.

Setup

After logging in, the user interface was pretty helpful in pointing me in the right direction. On the first page, I could see a red “add more” button, which I used to add test agents. There were a lot of steps required to get the agents functioning completely. This is because we had to use the right package file, install it, edit the php.ini file and restart some services. However, within minutes I had an application agent up and running. Setting up server monitoring agent was a breeze after installing the app agent. There were two setup process for the two agents, which made me ponder: why are there even two? It would have been nice to see an all-in-one agent that could be installed.

Navigation

I began exploring the application navigation pane after the agents were successfully registered. My first impression: Wow! How about those charts? Two vital pieces of data were the Apdex chart, and Web transactions. Apdex is a simplified Service-Level Agreement that gives a single quantitative rating of how customers might be reacting to the site’s performance. This is based on response time. Find out more about Apdex here. Web Transactions allow users to go through the PHP transaction traces and pinpoint methods causing poor performance. Web transactions can be sorted by the following four conditions:

  • Most time consuming
  • Slowest average response time
  • Apdex most dissatisfying
  • Highest throughput.

Experiment

Now that the app/server agents and test environment were ready to go, it was time to begin testing. While the test was running, the New Relic team gave us a comprehensive demo of their monitoring application.

Some of the most time consuming transactions in our test environment

If you’re not interested in drilling into the details of the application, you could always just inspect the response versus time graph. This helped the team see the effects of a load test on a server over long periods of time. In fact, there is some correlation between the load test results from LoadStorm and the response time graphs from New Relic together.

LoadStorm test results and New Relic response time aligned by time (approximate, click to expand)

It’s not perfect because the scaling is off, but there is definitely correlation between the two data sets. This is an indicator that our system is being successfully load tested and monitored.

Conclusion

Overall,the team was impressed with the features and ease of use that New Relic offered. Their monitoring services cover both the application and server. A further benefit includes the quick-filtered transactions, which are useful for web developers and performance engineers alike. The support team was helpful in getting us well acquainted with the application. I am happy to give New Relic a positive review and would recommend it to anyone looking for optimize their web app because of the advanced detail provided. Subscribe to our feed and find out what we think of the next monitoring service provider: AppFirst.

Similar Posts