The new metrics are located under the JVM tab and include the following:

* Loaded and unloaded class count for the JVM
* Active thread count for the JVM
* Active and idle thread count for each thread pool
* The ratio of active to maximum thread count for each thread pool
* Active, expired and rejected HTTP session counts per application
* Active, finished and created transaction counts per application server

Now let’s take a closer look at each of them:

Loaded & Unloaded Class Count

Location: Under the Memory tab in the bottom-right corner of the screen.

Supported Application Servers: All application servers that have JMX enabled.

Use Cases: The loaded and unloaded class count can be used for a variety of purposes. For example, if the loaded class count is constantly going up, then the app server or a class loader may have a bug. Or if you perform upgrades without bringing down the JVM, you can use it to verify that classes were unloaded and then reloaded.

Active Thread Count

Location: Under the Threads tab.

Supported Application Servers: All application servers that have JMX enabled.

Use Cases: You can use the thread count to determine how many active threads are running in your application. This is useful for determining usage trends. For example, it can show the time of day and the day of the week in which you usually reach peak thread count. In addition, the creation of too many threads can result in out of memory errors or thrashing. By watching this metric, you can reduce excessive memory consumption before it’s too late.

Thread Pool Metrics

Location: Under the Threads tab.

Supported Application Servers: Tomcat, JBoss 5 and 6, Resin, Jetty, WebLogic, TomEE, Glassfish, and WebSphere

Use Cases: Thread pools are typically used to service multiple requests simultaneously. However, to get the best throughput, thread pools must be configured appropriately. For example, if the maximum thread count is set too high, the app will slow down from excessive memory usage. But if the maximum thread count is too low, it will cause requests to block or timeout.

You can use these metrics to see if you are reaching the maximum thread count in a pool. In addition, they can be used to tune other properties – such as the amount of time before an idle thread is destroyed and the frequency of when new threads are created.

This graph displays information on the http-bio-8080 thread pool on a Tomcat 7.0 application server. It shows that the thread pool starts with 10 idle threads and never handles more than five active requests at a time. The 0.23% capacity indicates that the number of active threads is well under the limit.

Session Metrics

Location: Under the HTTP Sessions tab.

Supported Application Servers: Tomcat, JBoss 5 and 6, Resin, TomEE, Glassfish, and WebSphere

Use Cases: HTTP session information is used to determine usage trends such as the time of day when an application is getting the most amount of traffic. It can also be used to tune configuration properties such as the maximum number of active sessions allowed at one time and the amount of time a session remains active. For example, a high rejected session count usually indicates that the maximum active session count should be increased. Meanwhile, a high expired session count can suggest that the session timeout is too low.

The graphs below show session information for two applications. The first indicates that a maximum of two sessions have been created for the application ‘examples’, but the sessions are constantly expiring. After increasing the timeout, the number of expired sessions reduces to zero. From the second graph, we see that zero sessions have been created for the application ‘host-manager’.

Transaction Metrics

Location: Under the App Server Transaction tab.

Supported Application Servers: JBoss 7, Resin, and Glassfish

Use Cases: These metrics show info on transactions that go through the application server’s transaction manager. They are used to show transaction traffic patterns and help to configure the transaction manager.

Get Started Today
New Relic uses Java Management Extensions (JMX) to gather data on these new metrics. Before you get started using these new metrics, you must update to our latest Java agent and enable JMX on your application server.

You can also set up New Relic to show custom JMX metrics. To see how to display custom metrics, watch this video.

The post Dive into your JVM with New Relic appeared first on New Relic blog.

RailsConf 2013 is right around the corner! And to celebrate, we’re publishing a series of blog post that highlight what’s new and exciting in the world of New Relic’s Ruby support. Don’t forget to check out the entire series so far: Cross Application Tracing, Thread Profiling, Living on the Edge with Rails 4 & Ruby 2, and Thread Safe APIs & Sidekiq Support for Your Threading.

Over the last few months there’s been a lot of traffic on the rubyonrails-security list. High profile remote code execution exploits were found in both Rails and Rack, which heightened the focus on security in the community. It’s also brought increased scrutiny from security researchers probing for more vulnerabilities. Overall this will lead to more secure versions of Rails and other frameworks. The discussions also help more people consider their own applications’ security.

However, there’s the lurking issue of unpatched applications. Lots of people have Rails apps deployed they may not realize are vulnerable. It could be that small app a consultant installed two years ago that’s been chugging away untouched since. Or maybe it’s an experiment that got uploaded to a cloud service last year before being forgotten. It’s easier than ever to lose track of applications, and depending on your configurations and infrastructure, one insecure app can impact far more than just that app’s functionality.

New Relic’s Ruby agent has always reported the gems active in the application’s environment. That information has been useful for debugging and guiding us toward other libraries to instrument.

Brand new in time for RailsConf 2013 we’re taking advantage of that information to notify you of vulnerable versions of Rails and Rack. For Rails we check against versions 2.3.x and 3.x. Rack gets checked across versions 1.1.X through 1.5.X.

When we find a vulnerable version of these gems, you’ll see a banner in the New Relic UI pointing to the application and problematic gems. Additional links to the relevant development groups online will also let you dig further into the issues and learn more about the vulnerabilities.

Here’s to a more secure future!

Headed to RailsConf 2013? Stop by our booth to see the New Relic Ruby Agent in action, pick up your free Data Nerd t-shirt and more. You can even try New Relic Pro free for 30 days. For more information, go to newrelic.com/railsconf.

The post Security Banners (For If You Forgot to Apply the Latest CVE Patch) appeared first on New Relic blog.

The Scoop on SmartOS
SmartOS unites extraordinary technologies to create a high performance cloud infrastructure: OpenSolaris, ZFS, DTrace, Zones and KVM Linux. These technologies are combined into a single operating system, providing a highly multi-tenant and resilient environment built on an enterprise-grade storage stack. SmartOS is open source. However, many of you will opt to leverage Joyent’s hosted infrastructure for your web application. SmartOS is built for real time web and mobile applications. That’s why Joyent built it and continues to support its maintenance. SmartOS is an innovative hypervisor platform that supports both KVM hardware virtualization and operating system level virtualization.

New Relic Server Monitoring
New Relic Server Monitoring lets you watch system-level metrics like CPU usage, physical memory, network activity, processes, and disk I/O. This is perfect to use in tandem with one or more of our app agents for PHP, Python, Ruby, .NET, Java, and Node.js. (Our Node agent is currently in beta.)

The processes view highlights the processes that are hogging up resources by memory or CPU. These are further dialed down to a specific time slice so you can dig into spikes at your peak usage times. Server Monitoring includes beautiful charting of usage metrics so you can see the peaks and valleys of your server resources. This data can also be viewed in tandem with your application data by taking advantage of custom dashboards.

With Server Monitoring, you can also customize thresholds for alerts. Alerts can be set by CPU utilization, disk utilization, memory usage, and disk usage. These thresholds can be used to drive alerts and push them out to HipChat, Campfire, PagerDuty, and even the New Relic iPhone app!

Did I Mention it’s Free?
New Relic Server Monitoring is free and you can use it on an unlimited number of servers at no cost. How cool is that? Sign up now!

Installing New Relic Server Monitoring on SmartOS
You can install New Relic Server Monitoring on your VM in Joyent’s cloud from their pkgsrc repository. Pkgsrc is a SmartOS-optimized package repo, sort of like a yum or aptitude for SmartOS packages.

First, you need to have a New Relic account. Sign up here if you haven’t already.

You can learn how to install the Server Monitoring agent on SmartOS at our Help Center.

Getting Started with Joyent’s Public Cloud
If you haven’t kicked the tires on Joyent’s cloud hosting, you should give it a spin. It’s especially good as a high performance hosting solution for Node.js, another project that Joyent is well know for open sourcing. For more information, see Max Bruning’s article on how to get a SmartOS VM setup with LAMP stack.

More Info
For more information about New Relic’s Server Monitoring features, check out our documentation site.

Happy Server Monitoring!

The post New Relic Server Monitoring Now Available for Joyent SmartOS appeared first on New Relic blog.

If New Relic already gave you x-ray vision, then X-Ray Sessions give you super x-ray vision! Here’s how it works: Suppose there’s a performance issue you’re trying to get to the root of, but you can’t quite figure it out with the default set of analytics we provide out of the box. For example, 99% of the transactions work fine. But there’s one that grinds to a halt or errors out due to specific customer data.

Simply run an X-Ray Session on a Key Transaction. You’ll immediately begin to collect up to 100 Transaction Traces and a thread profiler report that aggregates all your hosts. And it will show you the performance of that Key Transaction at the most detailed level possible. You can leave it running for hours in the background and be confident that you’re collecting the most detailed diagnostics data possible.

The best part is that the overhead is minimal. Because the additional TTs and thread profiler are targeted only for the Key Transaction, the rest of the app incurs almost no additional overhead. X-Ray Sessions can then be saved and shared across your team as you continue to work through those really tough performance issues.

X-Ray Sessions are launching for Python, but we have plans to quickly follow up with support for Ruby and Java. And of course, PHP and .NET aren’t far behind either. So if you’ve got a Python app and want the ability to have super x-ray vision, then upgrade to the latest agent and let us know what you think of X-Ray Sessions today!

The post Super X-Ray Vision with X-Ray Sessions appeared first on New Relic blog.

Join us next week to see just how New Relic for Mobile Apps works. We have three webinars for you to choose from:

* Tuesday, March 26
* Wednesday, March 27
* Thursday, March 28

All webinars take place from 11 am – 12 noon PT / 2 pm – 3 pm ET. Space is limited, so sign up today to save your spot.

And if you haven’t tried New Relic for Mobile Apps already, what are you waiting for? You’ll have 30-days to try New Relic for Mobile Apps Enterprise for free. Visit newrelic.com/mobile for more information.

The post Webinar: See New Relic for Mobile Apps in Action appeared first on New Relic blog.

Until now, there has been no way to have actionable insight into the performance of your apps.  With multiple points of possible failure, whether deep within the application code, in the mobile device itself, or in calls to third party APIs such as Facebook, PayPal and Twitter, you could only guess at the quality of the user experience and the precise location of performance bottlenecks.

Introducing New Relic for Native iOS & Android Mobile Apps
Today we’re excited to announce the availability of New Relic for Mobile Apps. Now the same powerful, real time performance data you’ve come to rely on is available for your native iOS and Android applications. For the first time ever, you’ll have in-depth insight into real users, sessions and finger swipes as they happen.

With New Relic for Mobile Apps, you’ll be able to:

* Gain visibility into the health of your native mobile apps
* Provide faster, more reliable apps to your customers
* Constantly monitor the health of services that your app depends on for its success
* Get detailed network and web server level error analysis

New Relic for Mobile Apps is deeply integrated with New Relic for web and mobile browser applications. It shares the same one-screen view, making New Relic’s combined services and capabilities the only solution to monitor software, no matter where it’s running in an app server, browser or mobile device.

Expanding Our Partner Ecosystem
In addition, we’ve expanded our world-class partner program to include new relationships and partnerships with the industry’s leading mobile app platform providers: Adobe PhoneGap Build, Appcelerator, Parse and StackMob.

We’ve also extended our partnerships with CloudBees, Rackspace and Windows Azure Mobile Services to support their mobile application capabilities.

Try it FREE for 30 Days
For a limited time, you can try New Relic for Mobile Apps Enterprise free for 30 days! It takes less than minutes to sign up and deploy the New Relic Mobile SDK into you application. You’ll quickly start seeing data and wonder how you ever got by without it.

Want to see New Relic for Mobile Apps in action? Check out one of our upcoming webinars. Space is limited, so reserve your spot today!

The post Breaking New Ground with New Relic for Mobile Apps appeared first on New Relic blog.

New Relic is going completely mobile. Back in January, we launched the New Relic for iPhone app (available on the Apple App Store) that lets you go mobile while monitoring your web apps and servers. Now we’re taking that one step further by announcing support for monitoring native iOS and Android mobile apps.

Real Time Visibility Into Your Native Mobile App
Let’s face it. If you’re getting one-star reviews, complaints about your app being slow and flaky, and crash reports, it’s too late. Publishing a mobile app is exciting. And you should have real time visibility into your customers’ experience.

With New Relic for Mobile Apps, you’ll be able to answer two fundamental questions:

* Is my application performing well?
* If not, what can I do to make it better?

Introducing New Relic for Mobile Apps
New Relic for Mobile Apps lives inside every install of your app on every device to monitor the health of your app as it communicates with the world. It captures real time operational performance metrics, monitoring the health and speed of every server and web API your app talks to.

Use New Relic for Mobile Apps to see the big picture or drilldown into specifics by device, platform, wireless carrier or geography. You can also arm yourself with complete response details for server errors.

Making Your App Faster
Tuning your app in a development environment is not enough, as apps in the wild behave differently. In particular, the end user experience can vary greatly depending on the health of the web services your app talks to. With a global audience using hundreds of wireless networks and devices, you need to be able to clearly see which web services and individual requests are taking their own sweet time.

New Relic for Mobile Apps shows you HTTP request times broken out by server and URL, allowing you to find which requests are most common, the slowest and hogging the network with the most data. We make it easy for you to identify and improve the things that will have the biggest impact for your users. This is classic New Relic functionality for your mobile applications.

The Dangers of Relying on External Services
Think the services your app uses are error free? Think again.

The wrong error is as damaging to your user’s experience as a crash. It can be tricky enough to identify and diagnose errors when you control the service. (Heck we should know. We’ve built our business around making it easier). When it’s someone else’s API and 5% of your users are having a problem, life just got a lot more complicated.

With New Relic for Mobile Apps, you’ll get immediate insight into which services consistently produce errors and the response bodies of those errors.

Error traces are recorded every time a service call returns a 400 or 500 status code. They show you the full request URL and the actual response body. And for Android apps we’ll include a stack trace pinpointing where in your app the request came from.

Drinking Our Own Champagne
At New Relic, we use our own tools to monitor the performance of our applications. For example, we use New Relic to monitor our Ruby and Java infrastructure. And of course, we use our iOS agent to monitor the New Relic for iPhone app.

When we launched the iPhone app we started seeing 403 server errors reported into New Relic for Mobile Apps — lots of them. We reviewed the mobile code, checked our server logs and we couldn’t find any obvious problems. So some of us wondered if that was ‘just the way’ the API worked. Then we added Error Trace reporting.

Just ten minutes later, we were able to remove 80% of the errors. After a couple more hours, we’d removed them entirely. Being able to see the real server response made all the difference.

I Use New Relic On My Servers. Do I Get a Bonus?
The New Relic agent on your server correlates requests from New Relic for Mobile Apps using HTTP header signaling. In the New Relic for Mobile Apps UI, you’ll see the request breakdown differentiating between app, queue and network time. Now you’ll know at a glance if that request is taking forever to query the database or if it’s just a lot of data to download over the air.

Want to know more about what’s going on in your web app? Click the App server drilldown link and look at the very same transaction from the server’s perspective.

First Class Analysis
We’ve built first class analysis into New Relic for Mobile Apps. You can analyze and drilldown into network response time and connection failures by country, phone carrier, and device. You can also compare and explore changes between app versions. And you can even look at which devices are most common so you know how many people will use that tablet-specific feature request.

Since you may not control all of the services your app talks to, alerts can be configured on a per-service basis. This allows you to configure which services and what types of problems are important to your operations team.

Getting Started Today!
Getting started with New Relic for Mobile Apps takes less than ten minutes. Simply:

* Sign up for New Relic.
* Enter the name of the mobile app you want to monitor.
* Download our SDK and follow the instructions to add it to your app.
* Run your app in a simulator, emulator or mobile device and you’ll start seeing data in just a few minutes

While you’re at it check out the latest version of New Relic for iPhone, because now you can monitor your mobile apps from our mobile app. We meant it when we said we’ve gone completely mobile.

Want to see New Relic for Mobile Apps in action? Check out one of our upcoming webinars. Space is limited, so reserve your spot today!

The post A Developer’s Best Friend – Now for Mobile Apps appeared first on New Relic blog.

WHY MOBILE, WHY NOW:

Fact 1: eBay sells 10,000 cars a week on mobile and predicts billions in mobile commerce 

That is a staggering stat. The market tends to talk about photo-sharing apps (which also care about user experience!) and Facebook. But the reality is significant money is being spent on other mobile commerce apps and, just as the Internet proved, you need to manage the customer experience if you hope to get satisfied, return traffic. 

Fact 2: Network-connected native apps are becoming the new “end points” for enterprise apps

At New Relic, we’ve been monitoring billions of web pages each week being served on mobile browsers since our Real User Monitoring product launch in 2011. Our users have optimized their pages for this growing mobile use case, but until now, they haven’t seen the actual native app experience. As tablets and smartphones proliferate through companies large and small, there is a tremendous need for dev, ops and business tools that shed light on the end user experience. How do we know? Because our customers have told us they need this visibility.

Fact 3: Mary Meeker speaks the truth. Mobile allows us to re-imagine EVERYTHING.

Mary Meeker of KPCB updated her state of the Internet deck last year and commented that the mobile revolution is driving the “re-imagination of nearly everything”. New devices + Connectivity + UI + Beauty on mobile devices means everything — from getting a cab to buying a car to connecting with friends — is being re-imagined.  And because New Relic is already the management tool of choice for the backend of most of these revolutionary services, it only makes sense to extend the visibility to the newest, complicated end point: The Native Mobile App.

The New Relic team has been working on a native mobile app monitoring offering for about a year. We first prototyped it last spring / summer, and have spent the last several months making sure the user experience and product depth has the special “New Relic magic” that we try to infuse into all our products (ease of use, data visualization, and the out-of-the-box ‘it just works’ experience). With this first release, we think we are filling a gap in the market for REAL USER DATA, in real time, directly from native app experiences.  As this is the first release, we have a roadmap for more capabilities and you’ll see significant additions later this year. But we believe this is a great first step and hope you do, too.

We invite you to try the Enterprise version of New Relic for Mobile Apps free for 30-days. After the trial ends, new and existing customers get New Relic for Mobile Apps LITE free of charge. Go here for more information.

Below are snippets from some case studies we published today. The stories, in the words of customers who have used our mobile product in production, are by far the most eloquent words of praise that I can imagine.

Mirego

Dark Horse

Wanelo

Kwarter
“With the New Relic for Mobile Apps solution, New Relic is pretty much the only game in town. We now have a truly comprehensive view of our full environment: from a server infrastructure perspective, from an application server-side perspective, and from a iOS/Android client-side perspective.”

— Dustin Whittle, CTO, Kwarter

… And here is Mary’s original presentation:

KPCB Internet Trends 2012 by Kleiner Perkins Caufield & Byers

Want to see New Relic for Mobile Apps in action? Check out one of our upcoming webinars. Space is limited, so reserve your spot today!

The post Why Mobile, Why Now: 3 Facts That Support our Decision to Help Mobile Developers appeared first on New Relic blog.

We’re proud to announce that the New Relic iOS app now displays your New Relic for Mobile Apps data. So if you have a mobile app, and want to monitor its performance, you can do so from your iPhone.

The New Relic iOS App now includes network errors, API calls and number of active users for your mobile apps. Enjoy!

The post New Relic iOS App: Now With Yo Dawg Support appeared first on New Relic blog.

Heroku caps the amount of memory application processes can use. Heroku’s docs say if the app instances running within each dyno use more than 512Mb of memory they will begin to swap and eventually the virtual server (i.e. the dyno) will be restarted. When this happens Heroku will write R14 and R15 errors to the application’s log.

New Relic has put several graphs together on the instances tab which can help you tell if your app is using too much memory and being restarted by Heroku.

To test this out I deployed a Rails application to Heroku which intentionally leaks memory each request. I added this code to my ApplicationController:

# in app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  before_filter do
    $leak ||= ''
    $leak << ("a" * 1.megabytes)
  end
end

Now every time this app serves a request it will add another 1048576 characters to a string held in memory. Since this string is stored in a global variable it will never be GC’d and the memory will never be reclaimed.

I enabled New Relic’s uptime pinger which hits the site twice a minute to see if it’s responding. You can see the average memory for process increasing slowly.

Then I started hammering the site with requests. It’s easy to do this with a little taco bell programming:

while [ true ]; do
  echo http://murmuring-inlet-9631.herokuapp.com/
done | xargs -P 5 -n 1 curl

This will send a steady load of five concurrent requests to the site (you can control the concurrency number with xargs -P flag).

You can see resident memory usage spiking to ~ 450Mb, which is close to the Heroku servers’ physical limit of 512Mb. The server then starts swapping.

At this point heroku logs is filling up with messages that look like this:

heroku[web.1]: Error R14 (Memory quota exceeded)
heroku[web.1]: Process running mem=2260M(441.4%)
heroku[web.1]: Error R14 (Memory quota exceeded)
heroku[web.1]: Process running mem=2567M(501.4%)
heroku[web.1]: Error R15 (Memory quota vastly exceeded)
heroku[web.1]: Stopping process with SIGKILL
heroku[web.1]: State changed from up to crashed
heroku[web.1]: Process exited with status 137
heroku[web.1]: State changed from crashed to starting
heroku[web.1]: Starting process with command `bundle exec unicorn -p 37621 -c ./config/unicorn.conf.rb`
heroku[web.1]: State changed from starting to up
app[web.1]: ** [NewRelic] INFO : Starting the New Relic Agent.

Usually Heroku is nice enough to restart the dyno for you (which restarts all processes freeing the leaked memory). I did find some cases where the app crashed and wasn’t cleanly restarted, so it’s good to enable Availability Monitoring so you’ll know if your dynos get into a bad state.

We hope the instances tab helps you keep misbehaving dynos under control.

The post New Relic’s Instances Tab appeared first on New Relic blog.