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.
As a follow on to yesterday’s post about watching production logs, here’s something I did today.
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 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
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:
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.
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.
My company has put out a flash video thing where you can make Santa dance in various styles.
Our home in Redmond, WA is for sale. I’ve put together a page with some info and photos here.
Careful, this is a trick question!
The obvious thing is to call ‘expire_action’ to remove the cached entries for the specified action. However, the fragment cache path for an action includes the controller name, and the expire_action method is a method on the controller, so the only cached actions you can expire are ones on the current controller.
What this really means is that those of you with ‘Admin’ controllers have to pass the controller into the expire_action as part of the options hash. This is essentially the same as url_for(), because url_for() is the method used to build the fragment cache key.
Seems like this can be improved.
Similar to lighttpd’s X-Sendfile, the nginx web server/proxy can return a file directly. My action_cache plugin now supports this feature to give your action cached responses blazing performance.
Check the README for how to do this.
Thanks to Dan for pointing out that nginx can do this.