Blue Box Group Integrates RPM for Instant App Management for their Customers
30 April 2009 at 4:34 pm | Posted in Partners | Leave a CommentBlue Box Group, a leading Rails hosting provider, has integrated New Relic RPM into their management console, called Box Panel. Blue Box joined the New Relic Affiliate Program and has quickly seen the benefits of providing a value-added service like RPM to their customers.
Blue Box customers can set up a free RPM Lite account and immediately begin to monitor their Rails applications running on the Blue Box service.
“We really like what the folks over at New Relic have to offer which is why we’ve integrated New Relic’s monitoring into our Box Panel user interface,” said Jesse Proudman, Blue Box CEO. “This integration and partnership gives our customers fast and easy access to the leading tool for Rails application performance. New Relic shares the same values as Blue Box. We both want to create a highly valuable, but affordable service and give our customers great support.”
Blue Box’s Joe Clark has written a post describing the integration on their blog. In it Joe says “We’re excited for yet another feature we can bring to you, and hopefully you’ll find this plugin as helpful as we do for gaining greater understanding on the inner workings of your Rails site.
We are very pleased to see Blue Box extend the power of RPM to their customers. Several have already opened New Relic accounts and use RPM to monitor their apps every day. One of those is Aurora Feint, the maker of iPhone social games and creators of the OpenFeint mobile gaming platform. Check out OpenFeint if you are considering iPhone development.
New Version of RPM Now Available
30 April 2009 at 4:18 am | Posted in Product Update, RPM in the News, Support, Tutorials | 4 CommentsTonight New Relic released Version 1.3 of RPM. This version contains new features available for all levels of RPM. The three new features in this release are described below.
Apdex Support
This feature is available in all RPM levels. What is Apdex? Its a vendor-neutral, independent standard for measuring your users’ satisfaction with the responsiveness of your application. The standard is published by Apdex Alliance, the organization chartered with the creation and dissemination of the specification for the Apdex standard. Why did we implement Apdex support? So that you and your business managers — the business application owner — can have an agreed upon target for the performance of the application. If they say “the app seems to be slow today,” you can say “but we are actually meeting our Apdex target which you set.” The way Apdex scores work is that you set the target for the response time of your app or for specific transactions (controller actions.) This target is usually something like 1 or 2 seconds. The target is referred to as T. T is the level at which users will be satisfied with performance. RPM takes over from there, continuously scoring your whole app as well as any controller actions you want scored. The scores will appear on the Overview Dashboard and on an Apdex Dashboard. Try using the score. Begin by having a serious conversation with the business team about user satisfaction and show them the Apdex score. Refer to it when you hear those dreaded words “I think the app is slow today.”
Capacity Analysis
This feature is in our RPM Gold service. One way to plan for increased user traffic is to increase the number of instances in a host (mongrel or passenger.) Typically more instances, better throughput. But there is a trade off. More instances, more CPU, more memory, bigger hosts. Bigger hosts, bigger hosting invoice each month. This can be especially true in a Cloud deployment, like EC2. Its easy to increase instances and spin up new hosts. But if this increase in capacity is a knee-jerk response to what might be a temporary condition, you could end up with too much capacity and an expensive hosting charge. On the other hand, if you have not configured enough instances, all the tuning in the world won’t improve your throughput. If your queues get too long, your users will see the wait times lengthen. That’s bad. The new Capacity Analysis feature continuously analyzes your instance utilization and shows you vividly whether you are have too many or not enough instances. The page also shows you the ideal instance count so that you can “dial up or dial down” the number of instances. The goal is to find that sweet spot and then recalibrate it as your application and load changes over time. This is a powerful addition to the RPM capability. Its a must have for any application with heavy load and a moderate to large number of instances. Check out Bayard Carlin’s App Server Provisioning and Tuning article over on RailsLab. He used the Capacity Analysis feature extensively.
Custom Dashboards
This feature is in our RPM Gold service. Ever wanted to create your own RPM dashboard? You know there is all that incredible data collected by RPM. Ever been asked by your business team for a real-time view of the business transactions running through your applications? Now both of these are possible with Custom Dashboards. In minutes, you can create new metrics, select a display widget, add your logo or company name, pick out some meaty business metrics like number of new customer accounts created, purchase transactions, cancellations, or new subscribers, compare the numbers to this time last week, and bang! Show that to the boss and watch him light up. Where did you get this data? This is so cool! The great part is you already have the tool — RPM — and you already have the data. Now with a few minutes of HTML coding, you have a whole new set of flashy dashboards your whole team can use every day. This is big.
Not a Gold customer? Watch this space. We are going to have a very special announcement next week during RailsConf. But don’t wait. Sign up for RPM Gold now and you will get in on our special deal next week.
New RailsLab Episode Explores Optimizing App Server Configuration
23 April 2009 at 11:07 pm | Posted in Performance Tuning, Rails, RailsLab, Tutorials | Leave a CommentAt New Relic, we have split personalities – we create tools to help our customers’ Rails applications scale and perform; we use our own tools to optimize our own tools; and finally, we use our tools to manage our own service which happens to be one of the largest and most heavily used Rails apps in existence. Say again?
The guy who keeps the New Relic RPM service running is Bayard Carlin. He is our Director of Technical Operations. That means he is our ops team. He is responsible for maintaining the ongoing growth, scalability, security and reliability of our RPM service. No small feat that, since RPM has grown from zero to 18,000 applications under management in less than a year. RPM now handles more than 1.3 Billion metrics per day!
Bayard thought RailsLab viewers might find it interesting to see how the RPM site has evolved to handle the load and some of the lessons he learned along the way. A big shout out to the team at Engine Yard who have helped us every day with this ongoing challenge.
Take a look at his episode called App Server Provisioning and Tuning on RailsLab. Bayard describes how our architecture evolved to enable our data collectors to balance the distribution of the ever increasing data load from our customers applications. He also provides some d
etails about configuring HAProxy, mongrel queuing, and optimizing the number of mongrels. Bayard also gives a sneak preview at our Capacity Analysis feature which identifies how busy your mongrels are. This will enable you to continuously manage your server capacity. Capacity Analysis is coming to RPM soon.
State of the Stack – A New RoR Benchmarking Report on RailsLab
1 April 2009 at 6:10 pm | Posted in Performance Tuning, Rails, Support | 1 Comment
New Relic helps over 1500 Rails organizations monitor and manage their applications. This gives us insight into the application stacks used by developers around the world.
We recently analyzed all of the application instances which use New Relic RPM. We identified the OS, Ruby and Rails versions used and also identified all of the plugins in each stack. The results reveal some interesting information about how quickly the Rails community adopts new versions of Ruby and Rails; about which plugins they find useful; and about the operating systems most commonly used (uh, big surprise, it’s Linux…)
This week we published our results for the first time on RailsLab. The State of the Stack is a report which lists the most commonly used versions of Ruby, Rails, and plugins in actual production applications.
We must be careful to state that the plugin analysis is not a market share report. These lists are also not a complete list as they have been truncated for inclusion in the report.
Compare the benchmarks to your own stack.
RSS Feed
Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.
