During the past month, I've been trying New Relic on my personal blog. New Relic is a performance management tool. It can help to monitor, debug and optimize a site. It includes features like slow page request analysis, slow database query analysis, error tracking, scalability analysis, performance alerts, weekly e-mail reports, up-time monitoring and even very specialized features like Apache Solr profiling. It's a bundle of developer goodies that can be used on live production websites.

I'm a bit of a profiling geek. In my previous life, I spent a lot of time working on production profiling and performance optimization of Java applications. So when New Relic recently announced that they're working on support for PHP applications, I wanted to give it a try.

We began testing New Relic when the PHP version was still in beta. We believe it can make for a great service to add to Acquia Hosting and the Acquia Network. My site is hosted on Acquia Hosting which is why I have been testing it on my site. So far the testing has been good. We've helped New Relic fix a number of bugs during the beta test period, and in return New Relic has helped us to discover a performance problem in one of our deployment scripts on Acquia Hosting. Proof that New Relic is useful!

Now that we are past internal testing, I am excited to say that we will soon be bundling New Relic into the Acquia Network. Every Acquia customer will soon get access to a premium version of New Relic's monitoring tools at no additional charge -- whether you are hosting with us or not. Expect more detail from us soon on how to access New Relic as a subscriber.

New Relic requires a small 'agent' to be installed on your web server. The agent hooks into the PHP interpreter and sends the relevant information to a back-end for analysis and visualization. Because it hooks into the PHP interpreter, it can provide that deep, code-level visibility that is useful when debugging a performance problem. The New Relic agent also adds extra Drupal specific instrumentation -- and will probably add more over time.

I've only used it on my personal site, which currently runs on a regular Drupal 6. However, I'm quite keen to unleash it on a Drupal 7 installation to see what we can learn. In the mean time, I'm including some screenshots of what my personal blog looks like according to New Relic. If you're interested in improving the performance of your site and are a profiling geek like me, you should give New Relic a try.

New Relic uses Apdex, an industry standard for measuring the satisfaction of a user of an application or service.
New Relic conveniently separates database performance from PHP performance. On a busy system, that makes it easy to pinpoint bottlenecks.
New Relic tries to annotate performance problems to 'controllers' rather than to specific URLs. Thus, it automatically extracts 'Drupal page callbacks'. This is nice because when an application has thousands of unique URLs (/article/11/19/why-mysql-is-cool and /article/11/19/postgres-is-cool and so on) that are all handled by the same controller (e.g. node_page_view()).
This graph shows that most of my database time is spent reading and writing to the accesslog MySQL table. By disabling the access log feature in Drupal, I could reduce my database load roughly in half.


Peter (not verified):

New Relic looks useful. Most of the alternatives require different monitoring products for internal and external recording.

Accesslog and the cache figures are both interesting. Would be nice to have an active site monitored for a day with each type of cache off. I am particularly interested in the use of normal page cache versus aggressive setting. Does it do enough to be worth switching off some modules that prevent the use of the aggressive setting.

Part of the Drupal access log duplicates part of the Apache access log. A performance improvement would be to pass the extra Drupal information to Apache to include in the Apache log then drop the Drupal access log. I tried a similar approach on a Web site a long long time ago using an Apache mod that later disappeared.

The next best step is to change the type of database table used for the log or the SQL. You could switch to the Archive engine for that table or use defer in the SQL. Does the D7 database abstraction let us specify database options per table? The following would be useful and, if not in D7, a great project for D8.
* Different engine per table. (MySQL specific)
* Split tables out to other databases.
* Defer operations on specific tables.

Druplicate (not verified):

I installed this app and it's very helpful. Just a quick note to those trying to install this if PHP is running as CGI, FastCGI, or suPHP: Adding a label for the RPM display using a PHP directive like "php_value newrelic.appname MySite" won't work if you place it in htaccess. Only mod_PHP allows for that. I tried a new PECL extension called "htscanner" that is supposed to allow PHP directives in htaccess but it didn't seem to work. The solution is to do it in php.ini. In my case I had two sites running on the same VPS so it was necessary to have a separate php.ini for each site. The problem is that not everyone can run a custom php.ini file. I have root access to this VPS. Sometimes you can get the host to put a custom php.ini file in your /home directory as in my case. And while you're at it, any other directives in htaccess should then be put in the custom php.ini file as well, and if you can, move the rest of the contents of htaccess to httpd.conf for a performance boost.