If you use lighttpd as a proxy server, instead of using the FastCGI bindings, then you’ll find that my action_cache code to use X-Sendfile doesn’t work. The switch I was using to enable this feature was set in the process environment when lighttpd started the Rails process. The process isn’t started by lighttpd in the proxy case, so a new switch was needed.
I added a Request variable called HTTP_X_ENABLE_X_SENDFILE to do this. Set this to ‘true’, and X-Sendfile will be enabled for proxy requests.
I think this will only work with the new proxy code in the 1.5.0 lighttpd that Jan is currently working on. It still seems a little buggy, as I can’t get any response to the client with my settings:
One of the reasons a site can’t use page or action caching in Rails is because different types of users see different page contents for the same URL. For instance, logged in users may see user specific info on the page, whilst other users will see a generic page. Until now, that would mean that the page can’t be cached for anyone.
I’ve just updated my action_cache plugin to help work around some of these cases and allow caching for at least some of the requests.
You can now implement a method on your controller to tell the action cache whether the current request should be cached or not. With this, you can decide, for instance, to cache requests when the user is not logged in and not cache requests for logged in users.
Here’s what that code looks like:
This is a follow up to my previous post about the Comcast DVR
Lisa called Comcast to see what could be done about the crashing. It turns out that the Comcast customer service people can send an update to the device, but you must call in to get this. The device doesn’t update itself at a convenient time.
Now we have the software update. the thing hasn’t crashed in weeks. It is more unresponsive to user input, but the annoying crashing every hour or two is gone.
It would seem that having to call in to get updates is a process that can’t possibly be cost-effective for Comcast.
I’ve just checked in an update to my Rails action_cache plugin. The main change is that now, under the right conditions, the plugin will serve up the cache content using the X-Sendfile header supported by lighttpd and other web servers.
To use the X-Sendfile functionality, three things need to be configured:
The internal format of the cache has been changed to support the X-Sendfile code. Now the cache entry is stored in two fragments, one for meta-data and headers, the other for the response body.
The README has more info on how to set this up.
as well as the allow-x-send-file property for FastCGI and soon to be proxy-core configuration.
Install the code, follow the documentation, start the server, send the header. How hard could it be? Well, in some versions, it’s quite easy, however, the version of lighttpd I started with wasn’t one of them!
From my recent experience, version 1.4.13 with FastCGI just doesn’t work. Empty content all round, and no errors reading the configuration to clue me in to errors.
The 1.5.0 version of the code works great with FastCGI with the same configuration that doesn’t work for 1.4.13. However, the new proxy-core code doesn’t forward requests to my Mongrel instances. Probably an issue with my configuration, so I’ll play with this some more.
The proxy c0de in the 1.4.x codebase doesn’t do X-Sendfile, so that option is out.
I had the opportunity to use my action_cache plugin code in a project today. While adding the code to the project, I realized I could do a little better at caching than I had thought when I wrote the code some time ago.
I handled this case by implementing a custom fragment_key method. Mine now looks something like this:
Now I have different output cached for admin and non-admin users.
The Seahawks are down by 7, 1:30 left in the game, driving down the field when BANG. A large flash of light out the window and a small explosion, followed immediately by a clap of thunder!
Lightning hit the mast of a sailboat in the Kirkland marina, about 100 yards away, at our eye level. Now I’m awake!
Sadly, the Seahawks lose the game…
Ben has an update to the RaPT tool that allows you to search for plugins in his plugin directory from the command line.
e.g. rapt search memcache finds all the plugins that reference memcache.
The key thing is that no discovery step is needed, so the process is not dependent on every SVN server being available at discovery time, and is therefore way faster than the Rails plugin script.
Check out Ben’s post about the update
If you are working on multiple Rails apps at a time, and run them all on localhost with different ports, watch out for session issues as the default _session_id cookie is shared between the apps. This is because the browser only uses the host name, not the host and port combination for looking up cookies.
What this means is, if you set some session state in one app, and then set some session state in a second app, the first app’s session will be orphaned and your first app’s session will be gone when you try to retrieve it.
There are two ways to have apps not interfere with each other:
In your environment.rb file: