MySQL Tuning Tips with Scout

By Andre Bullet_white Posted in Plugins Bullet_white Comments Comments

If you’ve used Major Hayden’s MySQLTuner before, you know it’s a great source of MySQL optimization tips.

Now you can get MySQLTuner reports automatically delivered through Scout. All you need to do is install the MySQL Stats w/MySQLTuner plugin, or update the plugin if you already have it installed. You will be informed if:

  • the amount of memory you have allocated to MySQL needs adjusting
  • tables are fragmented and need to be optimized
  • query cache sizes, max heap sizes, or buffer pool sizes need adjusting
  • queries are requiring an excessive number of temp tables

Weekly Reports

You’ll get your first report right away after installing the plugin. After that, you’ll automatically get a weekly follow-up report, so your database stays nice and optimized. You can change the frequency of the tuner reports to suit your needs.

Here’s an example report of a MySQLTuner report.

In case you’re wondering—you don’t need to install the MySQLTuner script on your server. All you need to do is select the Scout plugin from the plugin directory.

Real-time Query Activity

In addition to the MySQLTuner reports, you’ll get real-time statistics on MySQL query activity:

Like all Scout metrics, these can be charted and compared, you can get alerts on thresholds and trends, etc!

Where Credit’s Due

A huge thank-you to Major Hayden AKA Racker Hacker for the MySQLTuner Script. Also thanks to Eric Lindvall for creating the original MySQL Statistics plugin.

Get Started!

Sound interesting? Install the MySQL Stats w/MySQLTuner Plugin and start getting MySQLTuner reports automatically.


Monitoring MongoDB

By Derek Bullet_white Posted in Plugins Bullet_white Comments Comments

Updated 3/21/2013The MongoDB Overview plugin discussed below has been split into 2 separate plugins: MongoDB Server Status and MongoDB Database Stats. The server status plugin reports global MongoDB metrics and the database stats plugin reports metrics specific to a particular database.

John Nunemaker of Ordered List knows his way around MongoDB, the high-performance open-source, document-orientated database. We were obviously excited to see that John created a MongoDB Monitoring plugin.

Like all Scout plugins, installing it is a button click away.

Mongo Monitoring Walkthru

John’s MongoDB Monitoring plugin gives both an overview of key Mongo performance metrics and a detailed display when you need to dig deeper.

The overview:

The details:

View a chart of each metric:

Mongo Q&A with John

At Scout HQ, I brought out some hot cocoa, lit a fire, and demanded that John reflect on MongoDB. You wouldn’t know it from his appearance, but John had some rather enlightening things to say.

Read More →


Oink + Request Log Analyzer = Rails Monitoring in one report

By Derek Bullet_white Posted in Plugins Bullet_white Comments Comments

If you’ve ever had to track down a memory leak in a Rails application (and who hasn’t forgotten to use will_paginate occasionally), you’re probably already familiar with the excellent Oink plugin by Noah Davis. Oink spits out the actions that are leaking the most.

Oink is a huge help when tracking down a memory leak. However, it doesn’t overcome my laziness. Tracking memory usage is extremely important – talk to any dedicated Rails host and they’ll tell you memory leaks are behind many crashed servers. To make monitoring memory usage less involoved, I needed 3 additions to Oink.

Read More →


The Page Load Paradox

By Derek Bullet_white Comments Comments

The irony is that, with broadband nowadays more or less everywhere, overall connection speeds have gone up by leaps and bounds, yet the time taken to load web pages seems only to have got longer.

- World Wide Wait, The Economist, Feb. 12 2010

For more than 40 years, a one second response time has been the accepted limit for giving users the feeling they are freely navigating an interface [Miller 1968; Card et al. 1991]. However on the web, we operate with a different set of rules – we’ll hear anything from two seconds to eight seconds as the limits for response time. Even at the most aggressive threshold, it’s 2x the limit for a free-flowing user experience.

ShowSlow, a nice web service for uploading YSlow data, illustrates that many (if not most) of the Alexa Top 100 sites have load times greater than two seconds. If this Forrester study is correct, we’ve got a lot of frustrated people out there (Forrester isn’t the first to relate response times to revenue). Despite the data, we seem to use faster connections to build richer interfaces, not faster ones.

So, do users really care about speed?

My grandma and grandpa used to tell me they got by with very little growing up, but it didn’t matter. Everyone else was poor – they didn’t know they were poor. Have we just accepted poor response times as the norm? If sub-second response times were consistently possible, would we ignore it and just build a richer, slower web page?


There's Scout in my Safari

By Andre Bullet_white Comments Comments

The smart folks over at Rails Machine are always quick on the draw. Still, we were impressed when developers Will Farrington and Mike Skalnik had a working Safari 5 extension for Scout within 24 hours after Safari 5 extensions were announced. I pinged Will for the scoop:

What does the Scout extension do?

The extension works in the background to update the toolbar icon with a badge indicating the number of active alerts on Scout. Additionally, if you click on the toolbar icon, it will open up the activities page on Scout.

Active Scout alerts will show a badge:

... which you can then see on your Scout account:

Tell me about building a Safari 5 extension.

Building the extension itself was pretty pleasant. The bulk of it was spent in writing the (asynchronous) cross-site AJAX requests; the actual integration with Safari's Extension APIs was really simple and well-documented.

Overall, the extension APIs are still pretty young, and that does show, but very well-designed too. It ended up clocking it in at just over 100 lines of JavaScript (including comments and my whitespace preferences). The Extension Builder itself is very easy to use when it comes to setting up the extension and building/signing it. I can't speak to how this compares to the development process for Chrome or Firefox, but I'm very happy with the experience I've had and I'm looking forward to seeing what new APIs they end up adding to Safari Extensions.

What are your future plans for the project?

Version 0.2 will probably be out in the next day or two with some minor improvements to various things. I definitely have some itches I want to scratch. The big one for me — which might not be possible with the current APIs without some hacks — is getting a drop-down menu working for the toolbar icon so users will be able to right-click and have access to a quick list of all those active alerts they can use to navigate right to individual alerts. Beyond that, my other goals are working on a better UX; stuff like a first-run alert letting the user know they need to enter account information and offering a nice way to do so without necessarily having to even open up the Preferences window.

The code is open source on GitHub and I certainly welcome contributions: all you need is some JavaScript knowledge and to take a gander at Apple's documentation for the Safari Extension APIs.

Well done, Will! We'll be keeping our eye on the project. Check it out for yourself here.


Scaling Illustrated

By Derek Bullet_white Posted in Examples Bullet_white Comments Comments

Last week we added a third web server to one of our reporting applications. We’ve been growing at a steady rate and we wanted to reduce the load across our web tier (losing one of the web servers could put too much traffic on the remaining server).

Before Will Farrington (one of the fine folks at Rails Machine) added the third web server to the load balancer rotation, we setup a couple of charts to watch the magic.

Scout’s charts now refresh as metrics are reported so we could quickly see the impact.

Did the third web server help? Here’s what we saw:

Server Load

Our third web server helped decrease the load across our web tier:

Scout’s Server Load plugin is installed by default on your server.

Request Distribution

We confirmed the change in request distribution across the 3 web servers:

Install either the Apache or Ruby on Rails Monitoring plugin to view request metrics.

We love seeing visual confirmation of a job well done!


Older posts: 1 ... 36 37 38 39 40 ... 68