Once again, we’ll kick off the event with an ‘Optimized Breakfast‘ on Tuesday morning (June 18) with our COO Chris Cook, where you can hear company news and meet the New Relic team. Sign up here — seats are limited. If you’re not an early riser, then come network with us at our happy hour from 6:30-9pm Wednesday in our room at the convention center!

Then, join us for Office Hours on Wednesday. Meet New Relic’s Senior Director of Product Management Patrick Lightbody and Software Development Lead Bill Kayser at 1:15pm in Exhibit Hall 1. This is a great opportunity to talk with them about visualization techniques. Sign up now to make sure you get in!

And don’t miss our presentations! Here’s the lineup of what we have in store for you.

* Tuesday, June 18 – ‘Choose Your Weapon: A Survey for Different Visualizations of Performance Data‘ with New Relic’s Bill Kayser and Patrick Lightbody
* Thursday, June 20 (10:30am) – ‘It’s 10pm. Do you know where your code is?‘ with Patrick Lightbody.
* Thursday, June 20 (2pm) — ‘Surveying the RUM Landscape‘ with Patrick Lightbody (New Relic), Ilya Grigorik (Google), Buddy Brewer (SOASTA), and Jon Fox (Torbit).

For a full program list, see the Velocity site.

It’s not too late to get your ticket – join us at the Hyatt Regency in Santa Clara, CA. We’ll be at booth #309. We look forward to seeing you there! Come get your Nerd Life t-shirt and don’t forget: conference participants can get our New Relic Pro free for 30 days.

The post Get Up to Speed at Velocity appeared first on New Relic blog.

It’s super easy to get started:

* Install New Relic using your standard build tools and processes
* Debug and release your app in Eclipse just like always
* Build your Maven app with New Relic – it’s now as simple as adding a dependency to your application’s pom.xml
* Launch the emulator and see your New Relic data
* Enjoy New Relic support for your shiny new application!

You’ll find separate installation instructions for Ant, Eclipse, Maven and Gradle in our docs section.  And don’t miss our previous blog post on getting started with Gradle. For an example of how to install Eclipse, see this install video:

Don’t wait — log in, deploy and see data like you never have before on New Relic’s mobile section.

The post Android Developer? We’ve Got a Special Treat For You appeared first on New Relic blog.

“When we design apps, one of our top priorities is to make the experience fun, fast and simple,” says Matt Vlasach, Director of Mobile Integration Services at Unwired Revolution. “There’s no better way to encourage widespread enterprise adoption than to make an app genuinely enjoyable to use.”

Helping Clients Collaborate More Effictively
For one client — a major player in the food and beverage industry — Unwired Revolution designed DocLink, a software solution for accessing enterprise content on iOS devices and Windows 7 desktops. With this app, salespeople and other mobile employees can access files and auto-generated reports stored on enterprise servers through a common and very secure RESTful API. Users can subscribe to content they find interesting and that content is then automatically synced to their mobile devices for offline availability.

Another client — a major utility — needed an app to make mobile device management (MDM) a more user-friendly process. Unwired Revolution made it easier for the company to manage devices and maintain security posture without exposing thousands of end users to a complicated ERP backend. “In both of these engagements, we wanted to enable seamless functionality for enterprise users in an attractive, intuitive UI,” says Vlasach. “The ultimate goal was to unleash more productivity by transforming difficult, inefficient processes into engaging work experiences.”

Solving Their Own Performance Issues
But an app can only engage users if it performs as expected. During test phases for client projects, Unwired Revolution often had its own share of performance hiccups. “At one point, a pilot end user reported an increase in ‘server errors,’ but we couldn’t identify the source of the problem or reproduce it,” says Vlasach. “Our only option was to review log files and debug traces, which is hardly an efficient use of developers’ time. Besides, we didn’t want to burden our clients with the task of troubleshooting. Our goal is to be proactive — to identify problems before our end users even know that something’s wrong.”

Vlasach was already familiar with New Relic before bringing it to Unwired Revolution. In fact, he’d been using the solution for apps in his side business for nearly a year. “From my own experience, I knew that New Relic could help us address our app performance issues and give us early warning of issues,” he says. “We installed it on our production servers in February 2013, and right away it gave us deeper insight into any errors we encountered going forward.”

Server Side & Mobile Monitoring
Server Monitoring was just the beginning. Vlasch and his team began using New Relic for Mobile Apps as soon as it became available. It immediately gave them greater insight into their mobile app performance. “We got the Mobile iOS SDK up and running in literally five minutes, and we were getting valuable information right away,” he says. “It was amazingly simple: just insert two lines of code, add a framework, then run the app … With New Relic for Mobile Apps, we can clearly see which calls are being made, which ones are failing, how fast the servers are responding, and so on. There’s so much comfort in having instant visibility into our app’s performance — just knowing that everything’s OK.”

New Relic enables Unwired Revolution to identify and address performance issues on a proactive basis — long before those issues impact end users. This lets his team spend their time on something other than troubleshooting. We can spend more time doing something productive rather than chasing down a problem,” he says. “The investment we’re making in New Relic is trivial compared to the time it takes for a team of skilled developers to search for the source of a performance issue. From that perspective alone, the software easily pays for itself.”

And most importantly, better performance means a better experience for Unwired Revolution’s end users. “Our DocLink application is a big hit,” says Vlasach. “Users are saying, ‘This app is fun to use. It makes my work so much easier.’ That’s exactly what we’re going for — and performance plays a huge role in making their experience more enjoyable. At this point, I honestly can’t imagine releasing a mobile app without help from New Relic.”

Learn More
Read the full case study to find out how Unwired Revolution gained full visibility into its enterprise environments with New Relic.

The post Case Study: Unwired Revolution Gains Full Visibility into Enterprise Environments with New Relic appeared first on New Relic blog.

Existing tools weren’t a good fit. Our actual profile kept getting lost in the noise of tools like Instruments.app. We quickly realized we needed something extremely lightweight. And since our Mobile SDK runs on many different types of devices, we knew we needed a tool that could be distributed easily across a device test lab (such as the one our friends at AppThwack have built).

With those goals in mind, we developed dPerf – a small on-device profiling framework. Metrics collected by the profiler are pushed to a Node.js service with JSON over REST and are stored in a MongoDB collection. The Node service then provides a view that renders the profile data with Google Charts.

And here’s the best part: New Relic is releasing dPerf as an open source project! It can be found on the dPerf New Relic Repository on Github. Read on to learn more about how it works.

The New Relic iOS SDK
Before we dive into the technical details of dPerf, let’s talk a little bit about the New Relic iOS SDK.

Our approach to application monitoring has two main phases: instrumentation and reporting. The instrumentation phase collects data about network activities, such as NSURLConnection delegate method calls, into a memory buffer. Then once per minute, the reporting phase sends the contents of the memory buffer to the New Relic server.

It’s important to capture profiles for both phases of execution. This is a pretty easy task. (The profiler just needs a sane clock and to run for more than one minute.) If we know the start times for the application, profiler, agent and agent reporting phase, we can easily identify samples from the different phases.

Profiling Strategy
The general strategy for profiling a system is universal: sample the system at regular intervals. Any overhead incurred by the sampling process itself should be calculated and corrected by obtaining an average profile for the sampling process over a large number of runs, and subtracting this time from the samples.

The sampling interval is a critical parameter for a sampling process. Sampling theory (specifically, the Nyquist–Shannon sampling theorem) states that we can only accurately sample a process operating at a rate of R by sampling it at a minimum rate of 2R. This minimum rate, 2R, is known as the Nyquist rate. For example, to produce an accurate profile of a system performing an operation once per second, we must sample it twice per second. Sampling at a lower rate misses detail and introduces statistical noise. A good description of the Nyquist rate as it applies to audio sampling can be found here.

It’s ideal to conduct the samples as fast as possible, but higher sampling rates require more system resources. And this defeats the purpose of a lightweight profiling system. A critical task then becomes how to identify the ideal sampling rate to capture all relevant information, while minimizing the impact of the sampling process.

We’ve tested varying sampling rates between 10 – 100 samples per second. And we’ve found that a rate of between 10 – 50 samples per second is enough for most apps that do a lot of network activity. You can find that sampling at a higher rate reveals some interesting ‘jitters’ from external processes such as push notifications, SMS and the like.

In this project, the sampled value is the total CPU time used by the process across all threads, which is an ever-increasing value. By computing the changes between values, we can establish the relative CPU used between sampling periods.

What About Instruments.app?
Instruments.app is an amazing application. For the majority of cases, it’s more than adequate for profiling applications as its memory allocation tracking and reference cycle graphs are great tools for memory profiling. Its value is much more limited for CPU profiling, especially on-device.

Instruments.app is great if you want to aggregate the time spent in a particular method, context switch and system call. Unfortunately, it’s also resource intensive. The performance of method calls will still be accurate relative to one another, but the profile isn’t indicative at all of application performance on-device. Additionally, some handy tools such as the Dispatch instrument are not available when you attach to a process on-device.

Also, Instruments.app doesn’t make it easy to export raw metric data. Let’s say you’re trying to analyze dozens of profiled runs across dozens of devices. You want a simple and automated solution to compare the results.

On-Device Profiling Client
The profiler client has two main components: the periodic timer and the value function that’s being sampled.

Creating Fast Timers
iOS provides a few options for creating periodic timers. The NSTimer class is the most straightforward way to create a timer. NSTimer works reasonably well for timers with long intervals, such as a task that runs each second or more. For sub-second timers, NSTimer starts to become less than ideal. According to the documentation from Apple, NSTimer resolution is limited to around 50 – 100ms, but timers operating on this magnitude can experience a large amount of variability in the time that they actually fire.

The better choice for high resolution timing is to use Grand Central Dispatch (GCD) source timers. These timers are extremely accurate and add a fairly small amount of system load even at intervals around 10ms (100 samples per second). Dispatch source timers also fire at more regular intervals and have less variability than NSTimers. If the application doesn’t require precise timing, you can specify a ‘leeway’ argument when you create dispatch source timers to allow for more variability. For example, a timer can be created with an interval of one minute and leeway of five seconds. In this case, the timer will fire every 60 +/- 5 seconds.

Apple’s Concurrency Programming Guide provides an example of creating dispatch source timers:

dispatch_source_t CreateDispatchTimer(uint64_t interval,
                                      uint64_t leeway,
                                      dispatch_queue_t queue,
                                      dispatch_block_t block)
{
    dispatch_source_t timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER,
                                                     0, 0, queue);
    if (timer)
    {
        dispatch_source_set_timer(timer, dispatch_walltime(NULL, 0), interval, leeway);
        dispatch_source_set_event_handler(timer, block);
        dispatch_resume(timer);
    }
    return timer;
}

Using this timer is straightforward:

- (void) start
{
    _dispatchTimer = CreateDispatchTimer((1.0 / _sampleRate) * NSEC_PER_SEC, 0, dispatch_get_main_queue(), ^{
        [self sample];
    });
}

This method will create a dispatch timer which fires at _sampleRate times per second. We want it to be as accurate as possible, so a leeway of zero is given. It operates on the main queue and invokes a block that invokes the ‘sample’ method.

Sampling CPU Usage
Now that we have a fast and reliable timer, we can turn our attention toward interesting values to sample. We’re currently interested in application speed, so we need a good source for CPU utilization data.

iOS provides a great deal of low level information through the mach kernel task API, which is defined in mach/task.h. Apple has little documentation for these functions on iOS, but analogues exist for other mach-based kernels such as XNU and Darwin. These functions behave in more or less the same way across mach kernels, so documentation and code examples using this API are highly portable to iOS.

To find the aggregate CPU utilization for the application, we perform the following actions:

1. Call mach_task_self to obtain the current task.

2. Call task_info to retrieve basic info about the task including CPU time from terminated threads.

3. Call task_threads to retrieve an array of active threads.

4. For each thread, call thread_info which returns accumulated CPU time, and add to total.

Since these are low level kernel interfaces, take care when you allocate and de-allocate memory for the various structures.

The method below is a slightly modified version of the method provided in this Stack Overflow answer:

- (double)cpuTime
{
    task_t task;
    kern_return_t error;
    mach_msg_type_number_t count;
    thread_array_t thread_table;
    thread_basic_info_t thi;
    thread_basic_info_data_t thi_data;
    unsigned table_size;
    unsigned table_array_size;
    struct task_basic_info ti;
    double total_time;

    task = mach_task_self();
    count = TASK_BASIC_INFO_COUNT;
    error = task_info(task, TASK_BASIC_INFO, (task_info_t)&ti, &count);
    if (error != KERN_SUCCESS) {
        return -1;
    }
    {
        unsigned i;

        //
        // the following times are for threads which have already terminated and gone away.
        //
        total_time = ti.user_time.seconds + ti.user_time.microseconds * 1e-6;
        total_time += ti.system_time.seconds + ti.system_time.microseconds * 1e-6;

        error = task_threads(task, &thread_table, &table_size);

        //
        // failed to retrieve thread list: we can't proceed any further.
        //
        if (error != KERN_SUCCESS) {
            error = mach_port_deallocate(mach_task_self(), task);
            assert(error == KERN_SUCCESS);
            return -1;
        }

        thi = &thi_data;
        table_array_size = table_size * sizeof(thread_array_t);

        //
        // for each active thread, add up thread time
        //
        for (i = 0; i < table_size; ++i) {
            count = THREAD_BASIC_INFO_COUNT;
            error = thread_info(thread_table[i], THREAD_BASIC_INFO, (thread_info_t)thi, &count);

            //
            // if the thread_info call fails, clean up and fail hard.
            // partial results are probably useless.
            //
            if (error != KERN_SUCCESS) {
                for (; i < table_size; ++i) {
                    error = mach_port_deallocate(mach_task_self(), thread_table[i]);
                    assert(error == KERN_SUCCESS);
                }

                error = vm_deallocate(mach_task_self(), (vm_offset_t)thread_table, table_array_size);
                assert(error == KERN_SUCCESS);

                error = mach_port_deallocate(mach_task_self(), task);
                assert(error == KERN_SUCCESS);

                return -1;
            }

            //
            // otherwise, accumulate & continue.
            //
            if ((thi->flags & TH_FLAGS_IDLE) == 0) {
                total_time += thi->user_time.seconds + thi->user_time.microseconds * 1e-6;
                total_time += thi->system_time.seconds + thi->system_time.microseconds * 1e-6;
            }

            error = mach_port_deallocate(mach_task_self(), thread_table[i]);
            assert(error == KERN_SUCCESS);
        }

        //
        // deallocate the thread table.
        //
        error = vm_deallocate(mach_task_self(), (vm_offset_t)thread_table, table_array_size);
        assert(error == KERN_SUCCESS);
    }
    if (task != mach_task_self()) {
        error = mach_port_deallocate(mach_task_self(), task);
        assert(error == KERN_SUCCESS);
    }
    return total_time;
}

Who Profiles the Profiler?
There is some unavoidable overhead incurred by adding a profiler to an application that can be corrected for with benchmarking. The average time it takes to perform profiling operations is calculated with repeated trials and then used to correct sampled data. This technique should be familiar to many low level and embedded programmers.

The strategy is simple:

1. Record a timestamp at the start of benchmarking.

2. Perform N trials of the benchmarked operation. This should be a tight loop that does nothing but execute the operation.

3. Record a timestamp at the end of benchmarking.

4. Calculate elapsed time by subtracting the start timestamp from the end timestamp.

5. Divide this elapsed time by N (number of trials) to obtain an average time per operation.

A generalized method for benchmarking could be written such as:

- (uint64_t) benchmarkWithTrials: (uint) trials andBlock: (dispatch_block_t) block
{
    // call the block first, warming up any method call table lookups
    block();

    uint64_t start = mach_absolute_time();
    for(int t = 0; t < trials; t++) {
        block();
    }
    return (mach_absolute_time() - start) / trials;
}

Fortunately, the function calls to retrieve the task and thread info are very fast. On an iPhone 5, gathering CPU information for all threads takes on average about 150 microseconds.

Profiling Server
At this point, we have a tool that can record CPU usage efficiently at regular intervals. What should we do with this data?

We could have printed sample values to a console log for analysis or even written a small UI to display the profile after the profiling session was over. A goal of this project was to enable profiling across a variety of devices efficiently and scraping dozens of log files isn’t a scalable solution.

Instead, we wrote a basic client / server architecture. The profiling client buffers sampled data until the profiling session is completed. The data is then translated to JSON and sent to a RESTful Node service over HTTP. Along with the sample data, the JSON structure includes information about the device, a unique identifier for the profiling session, sampling rate and the name of the test performed.

This allows multiple devices to run a variety of profiling tests while reporting back to the same server. Decoupling the system in this way provides a lot of scalability and flexibility in the distribution and timing of tests.

Not including static content, the Node server is made up of only about 70 lines of code. It has two jobs:

* Store incoming data into a MongoDB collection.

* Serve that data up using Google Charts.

The server handles data posts from profilers, as well as generating charts and data sets for analysis. The following modules are used to accomplish this:

* Mongodb: Node driver for MongoDB

* Express:  Amazing web framework for REST and MVC mapping

* Jade: Powerful templating for dynamic views

* stylus and nib: CSS preprocessor

* Google Charts: Google JavaScript library for easy chart generation

This article is a great tutorial for using some of these modules to build a web app.

Distributed Testing with AppThwack
One of the major challenges of mobile development is ensuring compatibility with the wide variety of devices available on the market. iOS currently runs on 16 different Apple hardware platforms and Android runs on several hundred. Trying to build a test lab to cover all these permutations or perform tests on the various devices would be both cost prohibitive and time consuming.

AppThwack is a young company with an innovative approach to mobile testing. They have an automated testing platform that deploys applications to hundreds of real devices, runs tests and returns all sorts of interesting information. Along with reporting test failures, AppThwack also gathers screenshots and log files from all the devices.

With the AppThwack platform, we were able to deploy dPerf to multiple devices easily. When each device finished its test, it sent the samples to our central test server.

Results
After all of the pieces were in place, it was time to run some tests. To establish a baseline, we first tested an application that was completely idle except for running the New Relic agent and Profiler. Technically, we also ran it without the New Relic agent to get a true baseline, but an empty chart is not very interesting.

This chart clearly shows the New Relic agent reporting after exactly one minute. It’s pretty fast, too!

When this same idle test was run on the AppThwack platform, the results were a a bit different. One testing option AppThwack provided is to send several hundred random events during the testing period. This caused the ‘idle’ moments in the application to appear more jittery than what we saw in first test, which essentially had no events being fired. We also saw some of the AppThwack initialization during application start and the beginning of the random event stream. The New Relic reporting call was still visible when its timer fired after one minute.

Next, we checked the behavior of an application generating a bit of network traffic. This test performed a HTTP request to the highly useful httpstat.us site every second. We began with a plain old HTTP 200 OK request.

We definitely saw a periodic process here, mixed in with the ‘noise’ from the random event stream. It’s interesting to note that even at this point in testing, the New Relic agent used so little CPU that it was indistinguishable from the other network traffic.

Ramping up the network traffic to 5 requests per second, we saw a familiar pattern. The chart looked essentially the same as the 1 request per second, but the periodic process was multiplied. The New Relic reporting call was somewhat visible here, as a ‘thicker’ line around 60 seconds.

Next we moved on to an application that used more CPU resources. The chart below shows an application that queries the U.S. Geological Survey website for a GeoJSON data set of all the 2.5 magnitude earthquakes that occurred in the last month. After the request was complete, the GeoJSON was decoded. This process repeated every five seconds. The JSON payload size was quite large — roughly 600 kilobytes — so this was also a good test for handling of large HTTP responses.

Here the periodic process was quite visible and by the ‘thickness’ of the spikes we saw that the parsing took longer to complete — about a second or so.

The final verdict was that the New Relic SDK added only a tiny bit of overhead — about 10 – 20ms on average. And this overhead was only detectable in an application that was mostly idle, which is a rare case indeed.

Source Code
Again, if you’re interested in trying out dPerf for yourself, you can find the source for the profiling system in the dPerf New Relic repository on GitHub. We hope you find it as useful as we did. Feel free to use and enhance this tool to suit your specific needs. Got some cool changes that you want to share? Send us a pull request!

The post Introducing dPerf – A Distributed Low Impact CPU Profiler for iOS appeared first on New Relic blog.

The New Relic Design Team is constantly working hard to improve our user experience by finding simple, usable solutions for complex display issues. I’d like to describe our experiences with a project we shipped today – our newly designed time picker.

The Power of Feedback
Below you’ll see a couple of shots from our old time picker:

After it shipped, we started collecting and documenting usability issues. We found a few things that kept coming up:

“It’s too hard to switch from one timeframe to another. I have to click the time span I want and then click the ‘Make it so!’ button at the bottom.”

“Ending now looks too much like Ending in the past.”

“The layout is awkward.”

We implemented double-click functionality on the time spans, but found that it wasn’t enough because it wasn’t very discoverable. And since we aren’t satisfied with that kind of feedback, we knew we needed to go back to the drawing board and find a better solution.

Reiteration
These screenshots show the time picker we released today:

We fixed the layout issues by using a vertical arrangement of parts instead of using a horizontal split. The time span labels are clickable, and dragging the slider immediately triggers a time window change. For the Star Trek fans in the audience, we kept the ‘Make it so’ button for when you make your historical selection ‘just so.’

There’s also a new ‘Performance since the last deployment’ link. If you’re configured to record deployments, you’ll see this link at the very bottom. To get set up with this feature (which we rely on heavily ourselves), go to Your app > Events > Deployments.

We hope this new time picker is an improvement for you. But change is no guarantee of success. Tell us what you think of the new time picker in the comments below.

The post Make It So Redux: Introducing the New Time Picker appeared first on New Relic blog.

Getting Started
First, you’ll need to update your SDK installation to the latest version. (Versions 22.0.0 and up will migrate your app to Android Studio.) After a few SDK Manager updates and restarts, you should see something like this:

Now you’re ready to export your application from Eclipse. Google chose Gradle as the new Android build system, so we’ll generate the necessary build files first. From the Eclipse menu, choose ‘File’ and then click ‘Export’. Under the Android folder, you’ll find ‘Generate Gradle build files’:

Choose the project you want to migrate and click ‘Finish’.  Next, exit Eclipse and fire up Android Studio. You’ll want to import an existing project. You can do it from the File menu or the wizard if you don’t have a project opened. Navigate to the directory containing your app and double click the build.gradle file:

Now you’re almost there! Check ‘Use auto-import’ and select the Gradle wrapper. Or you can choose a Gradle distribution location if you have Gradle 1.6 installed. (This will skip the step of adding a few files to your project directory.) When you click ‘Finish’, Android Studio will perform a few housekeeping tasks and open your shiny new Gradle project. Hurray!

Bonus Round
Now that you’re working happily in Android Studio, isn’t it time to add a little New Relic action to the mix? Don’t have a New Relic account? (Sign up for one today and get a free 30-day trial!)

First, merge the following into your build.gradle file:

buildscript {
  dependencies {
    classpath 'com.newrelic.agent.android:agent-gradle-plugin:2.397.0'
  }
}

repositories {
  mavenCentral()
}

apply plugin: 'android'
apply plugin: 'newrelic'

dependencies {
  compile 'com.newrelic.agent.android:android-agent:2.397'
}

Then add an import to your default Activity class:

import com.newrelic.agent.android.NewRelic;

And in the onCreate() method, add this call to initialize New Relic:

NewRelic.withApplicationToken("<your mobile app token>").start(this.getApplication());

That’s it! We’d love to hear about your migration stories. Let us know your experiences in the comments below.

The post Migrating Your Android App from Eclipse to Android Studio appeared first on New Relic blog.

Are you going to the Scala Days conference next week? New Relic is! In case you haven’t been there before, Scala Days is the annual gathering where developers who work with Scala and Scala-based libraries and frameworks can share their experiences and new ideas.

New from New Relic: Play! Support
So what goodness do we have planned for this year’s Scala Days? Earlier this week, we announced our support for applications that run all versions of the Play! framework. By tracking web requests across asynchronous activity (through Akka, Scala Promises and Futures and WS API), we provide a consolidated view of activities that affect your customer’s experience.

We also provide instrumentation that benefits other apps written in Scala, use Akka as a framework, or use Netty as a server. As part of this week’s announcement, we described our increasing focus on Java as a language and JVM as an ecosystem. Specifically, these include our improved JVM metrics and our newly launched support for the Play 2 framework.

By adding New Relic to your Play 2.x application, you can see your web transactions organized by controller method / function. You’ll immediately see summary data about what web transactions are called most often, where they’re spending their time, and overall throughput and response time. We provide you with performance insight into your web applications so you can very quickly find, diagnose and fix those pesky performance issues before your customers feel any pain.

New Relic at Scala Days
New Relic is proud to be a Scala Days Gold sponsor. We have three engineers attending the conference who can share how to use New Relic as a tool for performance-driven development.

Drop by the New Relic table in the Tiffany Lobby of the Hudson Theater. We’d love to talk to you about your Scala apps and how New Relic can give you instant insight into your apps’ performance, errors and bottlenecks. If you’d like to get a head start, installation is simple and you can enable performance monitoring insight for your application in just minutes!

The post Join New Relic at Scala Days appeared first on New Relic blog.

The post Software Dev Memes that make us lol ’round here @newrelic appeared first on New Relic blog.

Tonight, June 5^th, from 6 – 8 pm, our own VP of Engineering, Bjorn Freeman-Benson, will be leading a Tech Talk at Airbnb’s HQ in San Francisco. Bjorn will be speaking about ‘Airplanes, Spaceships, and Missiles: Engineering Lessons from Famous Projects.’ There’s still time to sign up through through the Airbnb Meetup group.

Then tomorrow, June 6^th, from 6:30 – 8:30 pm, don’t miss your chance to see New Relic’s new headquarters when we host the San Francisco Web Performance Meetup. Rick Viscomi will discuss ‘Waterfall AntiPatterns’. Get some tips on how to become a web performance guru, meet some cool people, and enjoy our awesome Nerdvana meeting space.

See you there!

The post Airplanes, Spaceships & Web Perf, Oh My: Ways to Meetup with New Relic This Week appeared first on New Relic blog.

As the only APM vendor to support Java, Ruby, Python, PHP and .NET, New Relic has always supported a wide range of technologies and platforms. And we’ve been running thousands of applications on top of JRuby for years. But in the last month we’ve put out a couple releases that are important because they highlight our increased focus on not just Java as a language, but on the JVM as an ecosystem. Specifically, these include our improved JVM metrics and our newly launched support for the Play 2 framework.

Better Support for the JVM Ecosystem
With our improved JVM metrics, we’re showing more data than ever that’s relevant to anyone running on the JVM, regardless of what programming language or framework they use. The data includes thread activity, HTTP session data, connection pool metrics, class load/unload counts, and more. And true to the New Relic spirit, we present it in a way that just makes sense. Although much of this data is derived from JMX values, we comb through them automatically for you so that you don’t have to worry about it (unless you have some advanced needs.)

To support the JVM ecosystem even further, we’ve also added Play 2 support for both Java and Scala. Although we already supported some versions of Play 1, Play 2 was quite a bit of a rewrite and embraced Scala much more extensively. To properly support Play 2, we had to tackle all sorts of new things. We added support for the Netty web server, support for Scala itself and support for the asynchronous development techniques that Play makes so easy to build with. This release is a big milestone for New Relic because it’s the first time we’ve supported two different languages (Java and Scala) with a single agent.

“We were very impressed by New Relic’s leadership in embracing an emerging asynchronous web framework in Play 2 and were thrilled to work closely with their engineering teams to integrate Play 2 into the New Relic monitoring suite.”

– Michael Bryzek, CTO & Cofounder, Gilt Groupe

Although this isn’t broad Scala support (yet!), it’s the first step in recognizing and supporting the JVM for what it really is: a large ecosystem of diverse languages, frameworks and libraries. We hope that these two features demonstrate our commitment to the JVM and give you a glimpse into our future plans at New Relic.

Have More Questions?

Q: What version of Play is supported?
A: We support Play 1.2.x and are committed to continuing support for the Play 2.x (2.0, 2.1, etc) line going forward.

Q: Do you support Java, Scala or both?
A: You can write your app in Java, Scala or a mix of both – it doesn’t matter to us. We’ll automatically trace through all the asynchronous handoff points that happen inside your Play app, regardless of your choice of language. In fact, because Play’s internals are written in Scala, we’re already doing the work of supporting a polyglot application under the covers – even if you’re writing your app in 100% Java.

Q: Do you now support any Scala application?
A: Not exactly. If you have an app written in pure Scala, or perhaps with a framework such a Lift or Finagle, we won’t automatically pick up everything like we do with Play. However, you’re welcome to utilize our Java API (which is totally compatible with Scala) to define some custom instrumentation. Specifically look towards the @Trace annotation, the NewRelic.setTransactionName() method, and NewRelic.setRequestAndResponse() method, which will allow you to turn any block of code in to a web transaction.

Q: Do you support Netty now?
A: In part. As of today, we’re not announcing full support for Netty. Anything that works for you is fully unsupported. However, Play utilizes Netty so much of the work was done. We hope to announce something more in the future.

Q: Do you support Akka?
A: Play utilizes Akka heavily for various concurrency and asynchronous operations, and as such we need to instrument it in order to trace complex, multithreaded Play transactions. However, that does not mean we generically support Akka in any environment. We continue to evaluate the best way to generically express complex async event flows and hope to share more in the future about our plans.

Q: How do you report asynchronous transactions?
A: Because a Play controller can execute multiple database and web service requests concurrently, we need to express all of those actions in an easy-to-understand way. If you’re looking at a transaction trace, take note of the “timestamp” column. It will tell you when each component ran and help you understand the concurrency of your logical transaction. In cases where multithreading and async are used under the covers (i.e., when an incoming request is routed to your Play controller), we’ll minimize that data to make it easier for you to focus on your async application code.

For aggregate metrics over time, we represent every segment of the logical transaction in a simple time-series stackchart. Each segment in the stack represents time spent in a certain logical part of the transaction. Note: With async and parallelization, the sum of the individual parts can be greater than the total transaction time.

Q: What are your plans for Scala in general?
A: We are very excited about Scala in general and are thrilled to be the first APM vendor to offer native Play 2 for Scala support. We’re continuing to evaluate other popular frameworks within the Scala ecosystem and will continue to add support for them as necessary. More importantly, we view this release as a major milestone as we now support Scala (for Play) on top of Java, Ruby, Python, PHP, and .NET.

Q: What about other JVM languages, such as Groovy?
A: Although our initial focus with this release is Scala, rest assured that we’re also considering other JVM-based languages. The good news is that most of them are compatible with our Java API, meaning that you may already be able to use them with a small amount of custom instrumentation. That said, we understand the convenience of native support for frameworks and platforms within New Relic and we’ll continue to evaluate and add support for new technologies over time.

The post New Relic and the JVM Ecosystem appeared first on New Relic blog.