CRAZ8

I’ve moved my blog to a different provider. It should still look the same. If you see something missing, please let me know!

The reports from people who have visited our house (it’s for sale) is that we have 8-10 big trees down, and luckily, only minor damage to some gutters.

Since we’re living in Kirkland now, and have almost no gas in our cars (good planning!) we haven’t made it out there yet.

The tree guy is 2 weeks out to come and cut ‘em up and take ‘em away.

big is defined as > 100 feet tall.

With power, internet access is returned too. We haven’t ventured out today to see how far the power extends, but we do have family coming over to take hot showers and do laundry, so they’ll know the extent of the local blackouts.

The action_cache plugin has just been updated. I’ve added the Cache-Control: max-age=x header, where x is the number of seconds set in the time_to_live parameter on the response object.

This setting will encourage the browser to cache the response for the amount of time the programmer has decided is Ok for potentially stale data to be cached.

Install the plugin from http://craz8.com/svn/trunk/plugins/action_cache

As a follow on to yesterday’s post about watching production logs, here’s something I did today.

tail -f production.log | grep "Completed in "

This shows me the reqs/sec for each of the URLs the user has requested. Its simple to then watch for those actions that a) get executed frequently and b) take a long time to run.

The key here is that you are watching real world traffic, and seeing how the actions perform under server load.

The Rails log file is a great way to see what your app is doing, but what do you do when the incoming request rate goes up, like on your production server?

Typically, you’ll be using tail to view the latest requests, and you’ll see something like this:

Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:42) [GET]
  Session ID: 88a032a331d5eca72e75e6880ec55016
  Parameters: {"action"=>"index", "controller"=>"my"}
...
...
Rendering ...
Rendering my/index
Completed in 0.10900 (9 reqs/sec) | Rendering: 0.06200 (56%) | DB: 0.03200 (29%) | 200 OK [http://localhost/]

Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:42) [GET]
  Session ID: 88a032a331d5eca72e75e6880ec55016
  Parameters: {"action"=>"index", "controller"=>"my"}
...
...
Rendering ...
Rendering my/index
Completed in 0.10900 (9 reqs/sec) | Rendering: 0.06200 (56%) | DB: 0.03200 (29%) | 200 OK [http://localhost/]

When you start getting a few of these a second, this method becomes unusable.

Here’s how I get around that, but can still watch in real time.

tail -f production.log | grep "Processing "

This gives me an output that looks like this:

Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:42) [GET]
Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:43) [GET]
Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:44) [GET]
Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:45) [GET]
Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:46) [GET]
Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:47) [GET]
Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:48) [GET]
Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:49) [GET]
Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:50) [GET]
Processing MyController#index (for 127.0.0.1 at 2006-12-06 18:55:51) [GET]

This is less informative, but allows me to keep up with what my server is doing in real time.

The next question is: What happens when I get so many requests that this technique becomes useless?

Thanks to David’s post about using nginx on Planet Argon, I’ve now switched to using nginx instead of pound for proxy serving.

Pound used to give me intermittent 500 errors, so hopefully nginx will be a little better in this regard.

My action_cache plugin was kind of broken for the expire_action call. I’ve now implemented expire_action in a way that will work with custom cache keys provided by your code. This code uses the Regexp verson of the expire_fragment method to clean up, so you don’t have to be very precise when providing the options parameter to the expire_action call (unlike the base Rails code)

This also has the advantage of working with REST actions that can provide many different formats. You only need to know the base parameters you used to cache an action and all generated formats will be expired.

To help with this, I had to re-implement the way the cache key is generated. If you’ve implemented a custom fragment_key callback, you will need to change your code to now implement action_fragment_key on your application controller, and process the options hash to override the current controller values so expire_action works. I’ll post on one way to do this later.

I also added a new method – expire_all_actions – to clear the entire cache in a single call.

Thanks to Dan for pushing me to get this done. It turns out I need expire_action to work on other projects too.

My company has put out a flash video thing where you can make Santa dance in various styles.

Check it out

Our home in Redmond, WA is for sale. I’ve put together a page with some info and photos here.

Log home for sale