The Navigation Timing Specification is a JavaScript API detailing the timing information of a page load. Available in most newer browsers (including IE 9, Chrome, and Firefox 10+), it helps developers test user experiences remotely and easily, and quickly optimize their websites and web apps for different types of users. We’ve recently started to leverage the API more heavily in our Real User Monitoring (RUM) feature. RUM captures a few key points in time in order to aggregate page load times:

* Navigation Start: When the user begins a navigation to a new page
* First Byte: When the requested page returns to the browser
* DOM Ready: When the page has been parsed into a DOM
* Page Ready: When the page has completed loading

In browsers that don’t implement the Navigation Timing specification, navigation start time is captured as a user exits the previous page (via the beforeunload event,) and written to a cookie. The value is read from the cookie as the next page loads. When the requested page arrives back in the browser, RUM estimates the first byte time via the execution of the RUM header (JavaScript injected into the top of a page) and DOM ready via execution of the RUM footer (injected into the bottom of the page.) The page ready time is captured via the window onload event.

However when a browser implements the Navigation Timing specification, RUM can get the timing information directly from the browser – without having to rely on cookies or the header and footer execution for estimates. You should notice that the RUM footer is still required for context information (account and application identifiers, host to report to, web transaction name, etc.)

Perhaps the most notable difference in the end result of the two measurement techniques is the relative breakdown of DOM processing and network time. Essentially, the traditional estimation of first byte time is late since it relies on the execution of the JavaScript header. The deeper into a page the header is positioned, the later the estimation becomes. However, overall page load times remain similar. The following diagram shows what happened to our site’s response time breakdown as we flipped the switch to use navigation timing data. We saw that network time shrinks, DOM processing time increases, and the overall response time remains the same.

Of course, the degree of change in a site’s aggregate page load breakdown will depend on how many browsers on the site support the Navigation Timing specification.

RUM builds more detailed browser traces from navigation timing data. The DOM processing segment found in standard traces is now broken into DOM loading and interactive segments. These reflect the document’s ready state. In addition to the traditional queue, web application, network and page rendering time segments, and traces built from navigation timing data may contain time spent in redirects, cache lookup, DNS, TCP, SSL, and reading the response off the network (when non-zero).

Remember RUM will continue to work in all browsers with both measuring techniques. Over time, we expect that more and more browsers will implement the Navigation Timing specification. This will simplify your data collection and provide you with a more detailed view of end user response times.

Last week, our friends at Code School shared a video describing how they use New Relic in their environment. The interactive learning company relies on many of New Relic’s features to deliver high quality user experiences to its customers. See how in this video case study:

* Engine Yard shares best practices for using New Relic with your Engine Yard Cloud or Managed account.

* Code School shows how they use New Relic to deliver a high quality user experience to their customers.

* O’Reilly describes how they gave the Velocity website a performance makeover.

* Joshua Bixby gives best practices for making sure your frontend optimizations perform as well as they test.

* Sastry Malladi of eBay discusses the performance implications of using various data formats and versioning.

* HP opens the public beta of their HP Cloud Services public cloud.

* Find out how startups are creating a new system of the world for IT.

* New Relic engineer Jose Fernandez shares his experiences switching to Vim.

Where do you start?

As web developers, we tend to be really good at thinking about how to tune our server-side code. But our users don’t care about how fast our servers are. They care about how fast their pages load. That’s a challenge for us — we have to start thinking about end-to-end transaction times and work on optimizing in-browser. With RUM data, that’s easy to do, but many developers are unfamiliar with how to start approaching the problem.

When tackling an optimization problem like this, I start on the end user transactions overview. If I’m lucky, I’ll find some low-hanging fruit. Looking at the data for our app, here is what I found:

It looks that, of all of the time spent loading pages, across all of our users, 73% was spent in one place! That’s some juicy low-hanging fruit.

PublicAccess::ChartsController#show is the page that renders when a user views an embedded chart. Many of our customers love the embedded charts and use them a lot. So I’m not surprised that it’s on this list. But the embedded chart is a very small page. It’s just a chart with a title. How could it be taking that much of the total end user time? And more importantly, how can I tune it?

The drilldown chart to the right shows me where this page is spending its time. The biggest chunk of time is spent in transit over the network which is no surprise. DOM processing time is the second offender. This is true for the aggregate data; let’s see if it applies to the worst offenders.

How bad does it get?
Scrolling down on the transaction drilldown, I get links to some browser traces. These are individual requests that had really bad performance. Let’s take a look at one of them.

An 8 second page load for a page that consists of a single chart!?! This needs some help. But look at that DOM processing time! It’s over 5 seconds! That’s awful. Let’s see what we can do with it.

What is DOM processing?
In order to tune this transaction, it helps to understand what DOM processing really is. It’s the time spent by the browser parsing the HTML and JavaScript, and applying CSS rules. If you have any script tags in the body of your document, their execution is part of DOM processing. In order to figure out what’s going on with this page, we need to open it up with either Firebug or the Webkit Developer Tools and look at the asset waterfall. Here’s what that looks like for a random embedded chart:

There’s a lot going on in here. Let’s look at the most important points:

1. We’re serving 165KB of minified JavaScript and 29KB of minified CSS. That’s a lot of code!
2. It’s taking 1.59 seconds for the RUM timing to end (the vertical red line, which is the body.onload event.)
3. We’re loading the chart data as part of the RUM time (see the data.json line.)

Now we’ve got some actionable data to use. Let’s start tuning!

Tuning the page
It looks like there are two simple things we can do to tune this page: reducing the size of our JavaScript and CSS, which will reduce download and parsing times, and also deferring the chart data.json call until after the body.onload event.

CSS tuning
On the backend, we use Sass to write our CSS. We’ve got our SCSS source files fairly well split up. At deploy time we generate the full CSS, concatenate the files and minify them into the CSS files that we actually serve. Looking at the CSS bundle we were using for this page, we had already thrown out a bunch of the component files. Our sitewide layout, grid structure and form styles were already gone. But looking at what was left, I found that we had a full copy of the CSS required to style all of the site-wide UI widgets we use. That includes charts, but also things like the recent events list, data tables, and all kinds of other stuff.

Since this page is serving embedded charts, I know that I only need the styles for charts and nothing else. So I pulled out the chart-specific CSS and threw it into another file. Then, the CSS for this page could just use the chart-specific CSS and not anything else. That’s a win.

JavaScript tuning
Now it was time to tackle the JavaScript. Similarly to our CSS, we use Jammit to package up and minify the JavaScript code. I took a look at what was included in the JS bundle for this page, and I found a few things. First, we have a lot of code required to handle the charting system. There’s a full copy of jQuery, a copy of Highcharts.js, some utility functions for handling banner messages, code for embedding Flash (since some of our charts are Flash, like our maps), the JavaScript for the Flash-based charting library we use when our users’ browsers don’t support Highcharts, and then the kicker: a full copy of jQuery UI.

Wow. Our little embedded charts page had all the code necessary for rendering accordion and calendar UI widgets, performing drag and drop operations, and all of the other goodies that jQuery UI provides. That seems like a bit much, doesn’t it?

A little investigation revealed that our wrapper system for Highcharts was a jQuery widget that depended on jQuery UI’s widget generation code. And so we’d included the whole library. In a few minutes I’d built a custom version of jQuery UI that only contained the widget generation code, and swapped that out for the full jQuery UI code.

Event tuning
The last thing to work on is the ordering of events. We’re loading the chart before the body.onload, but it doesn’t really need to happen that early. We can defer it for a bit and users will still feel that the page is snappy. We do what most jQuery users do and wrap all of our JS in the following pattern:

jQuery(function($) {
  // do stuff here, like load a chart
});

This is shorthand for the following:

jQuery(document).ready(function($) {
  // do stuff here, like load a chart
});

The business code here is attached to the document.ready event. This is a jQuery-specific event that’s closely tied to the DOMReady event. It fires when the DOM has been loaded. Once all of the JS that’s attached to the document.ready event has run, the browser will fire off the body.onload event, and the RUM timing will stop.

Looking at our chart loading code, we were following this pattern. I changed it around a bit, to this:

jQuery(body).load(function() {
  // do stuff here, like load a chart
});

This simple change deferred all chart loads, site-wide, until after the body.onload event.

Results
Let’s see what our page load looks like now that the CSS and JavaScript have been tuned, and we’ve changed our event sequencing a bit.

This looks a lot better! Once again, let me point out the important features:

1. Our JavaScript is down 67KB (41%) to 98KB, and our CSS is down an order of magnitude (91%) from 26KB to 2.5KB.
2. The chart data load is happening after the body.onload event, so our timing stops earlier.
3. It looks like we’ve shaved a half a second off of the page load time

This is great! But we’re not really sure how this is going to affect us in production yet. Comparing individual page loads, like this waterfall to the previous one, isn’t a great comparison. If you hit refresh a few times you’ll see that page load times can vary quite a bit. So I’m not ready to trust my half-second speed boost yet.

Production effects
The proof, as they say, is in the pudding. Let’s deploy our changes and see what happens. Thankfully at New Relic that happens relatively frequently, so my code was released 24 hours after I made my changes.

First stop: the RUM web page view for our transaction:

The two vertical lines are two successive deploys. The first deploy released the optimizations we made. You can ignore the second one — we had a minor regression in the first deploy, unrelated to the optimizations, that we patched.

It looks like we really did shave a half a second off of the page load times! And that half-second came out of the DOM processing time, which is exactly where we expected it to come from. Excellent! So far my expectations have been met.

By constraining the time window to a post-deploy only view, which I’m not showing, I saw that the transaction’s contribution to the total page load time is down from 73%, to 56%. That’s a great win. It’s still 56% though, which is largely due to the number of hits it gets. So there might be some more tuning to be done later. But that’s for later. For now, I want to quantify the effect of the tuning we did.

I’ll bet that our tuning had site-wide effects for two reasons. First, this one transaction is still taking up a significant proportion of the total page load time. Second, when we deferred the chart loading until after the body.onload event, we affected every chart loaded on our site.

Here’s a chart showing our sitewide RUM performance:

The good news: our optimizations had a site-wide effect! It looks like we shaved almost a half-second off of the site-wide page load time. The embedded charts page gets a lot of traffic, so tuning it gave us a lot of bang for the buck. If you look closely at the Apdex chart, you’ll see that we improved our Apdex score by almost 5 points!

Conclusions
All in all, the tuning work took only a couple of hours. I was lucky that we had some very low hanging fruit to work with, so I was able to get a lot of bang for only a little buck. It’s rare that a single web page has such a strong effect on site-wide performance. However even if you don’t have that advantage, you may still be able to make some big strides in tuning your end user performance.

Look for site-wide problems
The biggest wins we had came from removing excess JavaScript and deferring the chart loading. These tuning patterns weren’t all that specific to the one transaction we worked on. They’re patterns that you can apply everywhere. Let’s look at what you can do with your site.

Reduce the amount of code
It’s all too tempting with modern tools like Jammit or Sprockets to package up all of your JavaScript into a single file for download. This can be problematic for several reasons:

1. Too large JavaScript files aren’t cached on mobile devices, so they’ll be loaded on every page request by your slowest users.
2. Even if it is cached, all of the JavaScript has to be processed on each request. Some browsers are more clever about this than others and cache the parsed JavaScript code. But as developers we can’t rely on the browsers to do the right thing. With the explosion of devices and alternatives we’ve seen in the past couple of years, assumptions about how browsers do things are dangerous.

By serving JavaScript conditionally, you’re adding an asset request (or more) to every page load, and you’re decreasing in-browser cache hit rates for your JavaScript assets. But there’s a much bigger win to be had by reducing the amount of JavaScript that needs processing on each page load. The fastest code is code that doesn’t exist. Coincidentally, it also has no bugs.

There are two extremes here — a single, monolithic JavaScript file versus a single file for each page you serve. You’ll have to find the balance between those two, and that will completely depend on your site’s architecture. A single page load Backbone.js app will want a monolithic file; a more traditional web application will want more than that.

Similar arguments apply to your CSS rules. By splitting up your CSS and removing CSS code from each page load, you’re making the application of rules to each and every DOM element that much faster. Lean and mean is the way to go.

Don’t be afraid to re-define what “page loaded” means: it’s about users
The deferral of chart loading to after the body.onload event can be seen as sleight of hand. We simply moved the chart loading time outside of the RUM timer’s domain. It seems like that might be dishonest, like we’re cheating on our numbers, but we’re really not.

The RUM timer stops when the browser has rendered and the user is able to interact with the page. For our site, as chart-heavy as it is, that can occur before the charts have loaded. Users can orient themselves to the page, and start looking at summary metrics that are displayed outside the charts. Think about the humans using our site. Do they need the charts to start interacting with a page? No. Will the half-second it takes for the charts to load be noticed? Yes, but just barely. For the humans concerned, they feel as if the page has loaded when they can see the charts’ loading bars, so let’s use that perception to drive our tuning, and defer the chart loading. The body.onload should fire at the moment the user can start extracting meaning from the page. It’s up to you to decide what that means, and adjust your JavaScript code accordingly.

Performance matters!
Lastly, don’t forget that performance matters to your users. They don’t want to wait for your content: they want to engage with your content. Give ‘em what they want, when they want it and you’ll have happy users.

Happy tuning!

Available as a public beta, HP Cloud Services enables developers to build the next generation of web applications and changes the economics of deploying modernized applications. It offers enterprises a single-sourced hybrid delivery solution that spans traditional as well as private, managed and public clouds.

“As more and more organizations migrate their business-critical applications to the cloud, it’s critical that we partner with trusted leaders to provide our joint customers with effective tools for identifying and resolving potential application performance issues through the stack, from the end user down to the application line of code,” said Bill Lapcevic, VP of Business Development at New Relic. “Having this essential capability makes it easier for teams to ensure their apps are delivering the highest standard of application performance and availability.”

To start using New Relic with HP Cloud Services today, go to http://newrelic.com/about/partners/hpcloud.

If you’re working on anything web related, it’s virtually impossible to miss the Drupal invasion of the past few years. Drupal is a PHP-based, open source platform built by thousands of passionate developers from all over the world. Known as a Content Management System (CMS), Drupal excels at creating websites, blogs and intranets. But it can also be used for so much more. Today, Drupal powers a whopping 2% of all the sites in the world, including some major installations like The Economist, MTV and the White House.

A popular slogan in Drupal-land is “come for the software, stay for the community.” This speaks volumes about just how inclusive the community is. Drupal.org has over 648,000 user accounts and 10,000 developer accounts. And as of March 2012, there are more that 15,648 community-contributed add-ons (contrib modules) that are available to customize Dupal’s behavior and appearance, add new features, or alter and extend its core capabilities. The last DrupalCon in Denver gathered over 3,000 attendees.

Learning to develop in Drupal has a steep learning curve. I believe this is because it does things very differently than other systems. While this can be challenging to an experienced developer, there are numerous resources to learn from. And I hope this post will give you a bird’s eye view of Drupal’s many parts and how they all come together to create one of the greatest web systems out there.

Contrib: Building Blocks for Drupal Development
Normally with extendable open source systems, you have a community contributing “third party” plugins or extensions. In Drupal, these are called modules and the ones not shipped with the core Drupal installation are called contribution modules (contrib modules).

But here’s a very important distinction to be made. Contrib modules are not separate from Drupal the same way they are used in other communities. Instead this is an area where new ideas are bred and special use cases are handled. This is a vital part of the ecosystem – for every new major version of Drupal, some contrib modules are refactored and made part of the core.

If you install Drupal core as it is, you’d be able to create content and manage it to some extent. But let’s be honest, you’d create a rather crappy website. Instead what you should do is use both core and contrib modules as the building blocks of your site. By cherry picking them, you can build the exact site and functionality you want.

Many in the community label Drupal a Content Management Framework instead of a CMS. This description better reflects how you actually need to build the CMS yourself and how Drupal is a box of Legos you can use to do so. But as any ten-year old kid can tell you, you need to know which parts you need before you can build an awesome spaceship.

Entities and Fields
By definition, a CMS is all about content. In Drupal your content is packed into entities of different types, ranging from users and comments to nodes and taxonomies. These are abstract data types, representing a single piece of content.

From Drupal core you have a couple of modules like user.module and node.module which integrates with the Entity API to provide their own types. This API allows anyone to easily create custom entity types for special edge cases, using hook entity info(). More on this later.

By default your entities can automatically be retrieved from storage via entity_load(). However if you also install entity.module, then all entities are also given a full programmatic CRUD interface, to Create, Retrieve, Update and Delete instances of the given type.

The node entity type is to most sites the central type — it’s what editors normally create on a daily basis. Nodes are further broken down in bundles — a type of data template for your content. These can be anything from articles, FAQ pages, interviews, podcast episodes, etc. This all depends on your unique site.

Entities in and of themselves are just bare, boring objects. In order to save any meaningful data to an entity bundle you may add fields to it. An article could for example need a header image and a body text, while a user might require a name and a website address.

Fields are an examples of how contrib modules work. They were introduced way back in Drupal 5 by the CCK module. It was such a success with the community that the module was quickly adopted and kept through Drupal 6. Then it integrated into the core for Drupal 7, with the Field API.

The way it works is that modules define field types, like an image field, which can then be attached to a bundle and named “header image” for an article. When you then go and create an article, the field will be instantiated to hold that really cool cat picture.

Other field types include links, email address, geographic data, etc. Of course you can also add your own if you find that the plethora of contrib modules can’t cover your specific needs

Views for Lists
Now that you have your entities sorted, you will naturally want to list them and your other data too – whether it’s for a front page article listing, a “who’s online” list or a tag cloud. This is done using Views, a pluggable list generator module.

Roughly speaking Views work in two steps. First it takes your configuration and builds a query from it, which is sent to the backend. Your backend is normally a MySQL database, but it could just as well be a web service, an XML file, FTP server, etc. Views doesn’t care — it’s pluggable, remember? Second it receives the query result and transforms this into a list in your preferred format, ranging from your vanilla HTML <ul> lists to JSON and RSS.

As with most things in Drupal, you will create your views using a web based UI. But what’s most interest for us as developers is what’s happening behind the scenes. In the case of Views, you will basically configure a view object, consisting of handlers for filters, fields and sorting, styles for its output and various configurations.

A Views handler is basically a class that can query the user for configuration and then help build the query. There are field handlers that adds data to what the query returns, sort handlers to manage the ordering of results, relationship handlers which pull in extra data in related tables, filter handlers that sift the results to only pick specific ones, and so on.

Modules bringing a new type of entity field also often contain Views plugins for filtering on those fields, styles to format the fields and so on. This modularity means that when you have an edge case that isn’t covered by the default plugins, you can easily hook into Views and extend it any way you want.

Opposed to most everything else in Drupal, Views are very heavy on the object orientation. Your views are objects and their handlers, styles and plugins are objects. Everything is tied together by hooks (see below), which explains their individual module’s data structure, relation to other data and where to inject the various objects to do their job.

As always, database interactions will most likely be the biggest bottlenecks in your applications and because of this Views has built in support for caching. It works in two layers, where you can cache the raw results of the generated query and its themes output, individually. Of course the caching is pluggable as well, so you are able to extend and change the logic if you’re not happy with the default options.

Coming Up
Next week I will dig a little deeper into these subjects

Export with Features
Everything in Drupal is built through the web interface. Or should be, rather, since one common pitfall for many newcomers is to start digging into code and program all your features yourself. This is a big no-no and goes against The Drupal Way paradigm. This is an approach of building with existing blocks wherever possible to leverage all the work others have already done and will keep doing in the future.

But how will you ship it if everything you build is configured in the database? In particular — how will you ship continuous updates to an already deployed site? And no, building in production is never an option.

The answer is Features, another contrib module that allows you to export database configuration, diff between your export and the database, and flush the database configurations in favor of your exports. Together this gives you all the tools you need to work The Drupal Way with an easy point-and-click interface, while keeping all the benefits of having your site in code.

You also no longer have to make heavy database queries to put together your configuration, because they can be read from a file instead. Sure, disk I/O is also slow but with an opcodecache, like APC, that’s no longer and argument. Because you’re not running PHP without an opcode cache, are you?

I’d like to think that Features turns Drupal into one giant scaffolding machine. Definitely in a good way!

Extending Drupal

So it’s not a good idea to just dive head first into programming Drupal. Though for some cases you have no option but to do just that. Despite my definite bias towards Drupal, I honestly think for projects with a lot of these cases you should take a long, hard look at the requirements and perhaps consider other platforms to build upon.

If you still feel Drupal is a good choice then you are certainly covered as far as extensibility goes. Apart from being a box of blocks for builders to assemble, the platform also sports a nice base framework with several extension points for custom code.

In the majority of cases this means hooks – callback functions named in a specific format. It relies on string substitution magic and lots of function_exists() calls. In my opinion this is one of darkest corners of Drupalverse, but on the plus side it makes it really easy for beginners to jump right into Drupal development.

To understand how these hooks work in practice let’s say for example that you’re creating a module named newrelic. In it you want to run a piece of code on every incoming request and for that you decide to implement hook_boot(). So you open up your newrelic.module file (the module’s base PHP script) and enter the following:

<?php
function newrelic_boot() {
echo ‘Hello world!’;
}

And that’s it — you have now extended Drupal to print “Hello world!” on every page! Perhaps not the most useful extension, but still, you get the point.

A complete list of all hooks in Drupal core can be found at api.drupal.org. Also see example.module, which is a collection of examples and best practices for how you can extend Drupal with your custom modules.

If you’re someone coming in from an object oriented world, you may become confused by the data model in Drupal where the primary structure is an arbitrary array. It makes it impossible to code by contract and your code will consist of a lot of empty() and isset() calls, just to verify data integrity. This spaghetti architecture was amusingly highlighted by a recent April Fools joke.

But it does have its advantages, especially when it comes how easy it is to override core and contrib modules. Let’s say for example that you want to take over the login page of Drupal and replace it with your own. Then you first have a look at how user.module defines the page in its hook_menu() implementation.

function user_menu() {
return array(
‘user/login’ => array(
‘title’ => ‘Login’,
‘page callback’ => ‘user_page’,
),
);
}

Here it says that when someone visits example.com/user/login, the callback user_page() will be executed. If we want to replace that with our own callback we need to implement hook_menu_alter().

function newrelic_menu_alter(&$items) {
$items[‘user/login’][‘page callback’] = ‘newrelic_page’;
}

And all of a sudden, all visits to example.com/user/login will cause newrelic_page() to be called instead. Dead simple! This hook_x() -> hook_x_alter() pattern is very common in Drupal.

Premature Optimization is Evil
Drupal is very general purpose platform. Because of this it has been necessary to introduce several layers of abstraction, to make it suit as many use cases as possible. Of course in many cases this also means a severe hit in performance.

I agree with the critique that Drupal can be very slow. But I also firmly believe there is nothing you cannot fix and Drupal even makes this a relatively easy task. How to boost your performance is a subject for another article however. The best you can do is to remember that premature optimization is evil and instead you should focus on bottlenecks later when and if there really is a problem.

Until then — get to know your building blocks and keep scaffolding your site!

This post is written by Martin Samson of The Hotel Communication Network. We love when customers post about how they use New Relic in their environment. Martin posted it on his own blog, and we asked him if we could share it with our extended audience. He said yes. Thanks Martin!

Creating a fast RESTful API using CakePHP and New Relic
In early 2012, the development team at The Hotel Communication Network set out to build a RESTful API to simplify communication between the various components of our platform. Early in the process, we began to evaluate the different options available to us: Ruby on Rails, CakePHP, Django, Lithium and ExpressJS.

We had the following requirements:

* Rapid development
* Unit tested
* Wrap the database with a safe interface (CRUD)
* Be compatible with multiple languages

The application started as a simple CRUD interface to be completed with a two week deadline. All frameworks were up to the task, albeit CakePHP was well known by all of us.

Reasons we chose CakePHP:

* We already use 1.x extensively.
* Our database was already compatible.
* The IRC channel is vibrant.
* It’s easy to understand.

Development
We started development in late March 2012. None of us had any experience with the new version of the framework; as it was just released. Once all the entities were defined, we built the API from the outside in by defining how resources should be accessed, modified and created. A lot of time was saved because our database already followed CakePHP’s naming conventions; the bake tool was used to generate the models and their test skeletons; the validation rules, routes and controllers quickly followed.

CakePHP has matured quite nicely, associations are now lazy-loaded. Object loading greatly improved, you can easily apply “Objects on Rails“ principles. Most of the logic was moved from models to distinct objects resulting in slim controllers and not-so-fat models, with clean business objects. It allowed our models to handle only data concerns (validation and persistence) thus giving us faster unit tests. CakePHP’s move to PHPUnit made for better tests and reports.

Our app, code named Butterfly, quickly grew from a simple CRUD application to the core of our platform. Most business logic was consolidated, eliminating code duplication.

Finally, all the REST routes were manually specified to give us more flexibility and control.

Tips when using CakePHP:

* Use model validation for everything. Really. Use it to verify a related entity’s existence.
* Use components to wrap repetitive controller logic such as GET parameter parsing.
* Separate concerns between models and business objects. CakePHP 2.x allows loading any classes with App::uses(). See Objects on Rails by Avdi Grimm
* Use the whitelist when saving data. (See RoR / GitHub mass assignment security problem.)
* Write unit tests! We have over 300 tests and thousands of assertions.
* Use simple views combined with the RequestHandler. Our API is only accepting and serving JSON, but we could easily add XML.

Running Butterfly on Apache 2.2 + mod_php seemed fast on our development machines although it quickly crumbled in our staging environment. At that point, we really didn’t know what was wrong and why responses were getting slower and slower. We were blind.

Enter New Relic
New Relic is a real-time monitoring service built to help you squeeze performance out of your applications. We heard lots of good things about them from a newly employed engineer and Shopify’s Tweets.

The whole process of signing up, installing the PHP module and getting a t-shirt took less than 10 minutes on FreeBSD! We were blown away once we viewed the dashboard: it automatically detected the framework and produced useful, near real-time graphs. From slowest controller to detailed database queries, we could drill down to a specific section of the system to determine what needed be optimized. A great feature is the ability to backtrace from any SQL query to its callers.

To our surprise, CakePHP’s built-in authentication with ACL was the slowest part of the application, due to joining in the aro/aco/users tables. We also discovered one of our applications was not caching properly, requesting object schemas on each call.

NGINX + PHP-FPM is being marketed as a really fast alternative forapache + mod_php. The metrics allowed us to compare NGINX to Apache, within our environment. Switching to it resulted in a 100% speed increase!

New Relic enabled us to optimize early in the development process, gave us visibility and the metrics to back changes. We are now entering the production phase and New Relic will help us keep track of improvements, enabling us to deliver a better end-user experience.

“Using New Relic has helped change our internal business partners’ perception of IT.”

Nike is one of the most recognized brands in the world. Founded in 1964 by University of Oregon track athlete and his coach Bill Bowerman, it has grown to be a leading global developer and retails sales company of athletic footwear, apparel and sports equipment. The company now operates in more than 160 countries and has employees on six continents.

Nike’s online business is a significant and growing part of its revenue portfolio. In 2011, Nike.com and its associated eCommerce applications brought in over $650 Million in revenue worldwide. Since Nike knows web performance directly correlates to revenue generation, it has made fixing and correcting any performance issues a high priority.

Initially incident notification, performance triage and management were significant challenges for Nike.com’s eCommerce team. Although the team was using a variety of tools, it had little insight into production application server health. As its eCommerce platform grew rapidly, the team searched for a better way to ensure application performance and reliability.

“Our main challenge was insufficient insight into our eCommerce applications – no single pane of glass we could look at to see what was going on under the covers,” says Kevin Bartholomew, Nike Web Support Production Manager. “One tool told us the network was down. Another told us the site was slow. We didn’t have anything to see where the problems were, and definitely not what was causing potential issues.”

Nike’s eCommerce team found New Relic in 2011 and was quickly impressed by what it found. “We chose New Relic based on the features available, its ease of installation and its quick results,” adds Kevin. “Overall cost was important to us so the fact that New Relic was a SaaS offering was helpful. We really liked its simple intuitive interface and shallow learning curve, and best of all, we really appreciated its almost instant value.”

Today, the Nike web support team can identify and fix performance issues quickly. New Relic enables them to be much more proactive than reactive and the team is delighted. “Using New Relic has helped change our internal business partners’ perception of IT,” summarizes Kevin.“We have the data and the reports to know when we have fixed a problem. Everyone is more confident and more cooperative. Even within our organization, communication and cooperation have improved.” The result is that the team knows there is an issue before Nike’s customers know it – and that’s exactly what it wants.

See the full Nike case study to see how New Relic helps the Nike eCommerce team make fast online service even faster.

* Jelastic shares a tutorial on how to use New Relic on their Java hosting platform.

* Engine Yard CEO John Dillon explains how you can use the cloud for rapid-fire innovation.

* Solutions Architect Peter Yorke leads a webinar on how to use New Relic to monitor performance for applications running on the Joyent Cloud.

* Patrick Moran, our own VP of Marketing, asks how much revenue does it take to be a $1B public company?

* CDN Planet describes the best way to test your CDN before it goes live.

* Internet Retailers shows how Google is looking for ways to make the mobile web faster.

* Adam Sherk checks the PageSpeed scores for top 43 news sites and shares which have the fastest page load times.

* Developer Mike Cousins creates a NuGet package to make it easier to get New Relic running in an Azure environment.

On a monthly basis, Cinchcast’s media property, BlogTalkRadio, hosts more than 35,000 hours of original content, attracts over 13 million unique visitors, and powers 15 million streams and 175 million ad impressions. The Cinchcast team is keenly aware that site performance is critical to participant engagement. Therefore, the company sees performance as a critical factor for their continued success.

To deliver superior performance, Cinchcast needed insight and deep visibility into its applications components. It wanted to understand which components in the application were taking significantly more time than others and how fast the website loaded from an end-user perspective. “Initially we knew that certain pages took longer to load than we would like so we started there,” said company CTO Aleksandr Yampolskiy. “New Relic helped us quickly identify the problem spots so we could optimize them.”

Within five months of installing New Relic, Cinchcast improved its site performance by 40 percent. And today, its development team uses New Relic to track performance on all their sites. “We use New Relic like a x-ray to see into every aspect of our platform and determine what we can improve,” Alex adds. “It give us both the big picture and points us to specific areas where we can achieve the biggest performance improvements.”

As Cinchcast’s momentum and leadership in the audio publishing and broadcasting space continues to accelerate, it knows it has the tools in place to keep its audio platform running at peak performance. “We’re a growing company and our enterprise customers expect and need reliability and superior performance for every audio broadcast. We take performance seriously,” Alex concludes. “We monitor performance all the time, 24×7. Adding our weekly performance analysis and review session helps us to continually evolve and optimize our audio platform to support our rapidly expanding business.” And that’s exactly what its customers expect.

See the full Cinchcast case study for more information on how New Relic helps it deliver reliability and superior performance.