I’ve been trying to figure out the effect of this line in my Varnish config:
sub vcl_hash { if (req.http.Cookie) { set req.hash += req.http.Cookie; } }
It seemed to make sense, but I was having a hard time wrapping my head around its ramifications. I was looking at some of the docs on the Varnish site and at this great Varnish config walkthrough when the metaphorical lightbulb went on. By adding the cookie to the hash it’s effectively creating a per-session cache.
Hmm. An interesting tradeoff. On one hand it’s filling up my available cache with duplicate copies of the same content because the hash identifying the cached content is cookie-specific. On the other, it is delivering content from cache that wouldn’t normally be cached because of the cookie.
It all started with an itch. It was a really painful itch that involved a Drupal site that was essentially down due to load. I scratched it with the help of a few incredibly helpful blog posts I found, so now it’s my turn to add to them so someone else can benefit as well.
The Problem:
HALP! The site, it is sinking!A large school district wanted to replace their existing outdated static web site with a modern CMS. They chose Drupal as their platform. The new site was successful.
Too successful.
The average traffic of 5 hits/sec jumped to over 100 hits/sec and the server went into a swap death spiral.
Fear not! Help is on the way in to form of a couple of technological superheroes …
Pressflow and Varnish to the rescue!The mutually-complimentary combination of these two tools can vastly increase the number of users your site can serve. Here’s the what, why, and how:
Continue reading ‘Pressflow, Varnish and Caching … oh my!’
Since I run a lot of Drupal and Moodle servers, it’s a good idea to keep up to date on all the published vulnerabilities. I’d really prefer to have some tool that lets me know when a new vulnerability is found, so I don’t have to keep checking back at a bunch of different web sites on the off chance a new vulnerability has been found. Fortunately, the Department of Homeland Security has an excellent site that provides RSS feeds of the vulnerabilities in their database. Handy, but a serious case of information overload since the feeds cover everything in their database.
Hmm. Distinctly suboptimal. Perhaps this is a good time to play with Yahoo Pipes? I’d looked at it before, but had never gotten around to actually building a pipe. This seems like a nice simple thing to try. Continue reading ‘Dabbling with Yahoo Pipes’
When I first started working with Moodle servers, one of the things that bugged me was the fact that it required a complete install of the code for every site hosted on the system. While that’s fine for most circumstances, it really did not work well in our environment where we’re looking at potentially hosting hundreds of Moodle instances. So, in the fine open source tradition of scratching an itch by finding something someone else has done, modifying it, and then sharing it with the world … I give you shared-code Moodle, OSL-style.
First, though, credit where credit is due. Martin Langhoff posted almost all of what we needed to do here. All I needed to do is expand upon it to fit our needs.
Second, what the modified code actually does:
1) config.php looks in Moodle dirroot/multisite_config for an ini file matching the server name. I.E.: fqdn.domain.org.ini
2) If found, the ini file is parsed and used to populate the Moodle $CFG
On to the code!
Continue reading ‘HOWTO: Shared-code hosting for Moodle’