Ryan Tomayko writes about a new Git hosting service. It hooks into Lighthouse and Campfire, and looks web2.0-ish too.¹

1. Not that web2.0-ish means much, but that style of site is really easy to grok ↩

An argument against VPS hosting. I’m waffling on moving some of my sites to a shiny, new VPS, but I’m also pretty happy with shared hosting for most things.

Sadly, Dreamhost (this site’s generally happy host) has messed up again. I can’t imagine that it will be good for their business. They reacted well at least.

The Ruby community responds to Dreamhost’s complaints about Rails deployment. I actually thought that Dreamhost’s complaints were constructive¹, they run a large-scale host, and they get the Debian-aspects of it really well. I would be much more interested in Rails if deployment was as easy as bootstrapping is.

1. Not everyone did ↩

Dreamhost rants about How Ruby on Rails Could Be Much Better. An interesting perspective from one of the largest vhosting companies out there.

Scoble hits the nail on the head talking about Moguls, the serverless internet company:

How did Microsoft screw this up so badly? Let’s get this straight. Amazon used to be a book store. Now they are hosting virtualized servers for Internet companies. So much for having billions of dollars in the bank like Microsoft does, some of the smartest people in the world working in your research arms and having “monopoly” market share in operating systems.

I’ve used a few web hosts over the years, and they all suffer random failures¹. Hardware dies, power fails, major upgrades are botched, hosts are hit with DDOS storms, and other users fuck things up. It’s really a question of how well the host recovers, how well they keep you informed during the apocalypse, and how great their service is outside of the pain and suffering.

How do the hosts compare? Google.com was down 31 minutes last year, which is pretty damned good (a dandy 99.999+% uptime). Dreamhost² averages slightly better than 99% uptime³. Rackspace⁴ averages 99.9+% uptime⁵.

For a weblog, 1% downtime is a great balance for the price. For a small business system, %0.1 is pretty good, though it costs almost 100x more. Can you imagine what Google’s %0.001+ costs?

1. Last night, for example, our expensive work host lost power to their entire site ↩
2. A shameless plug for our happy host, who charges us USD$7.95/month ↩
3. 1% is about 80 hours/year downtime ↩
4. Another host I use, costing about USD$650/month per server ↩
5. For the machines I’ve hosted there, I’ve had about 10 hours of downtime per machine per year ↩

It’s a funny story. I’ve been testing out various styles of fun articles on the site to see if there’s any money to be made as a B-list obscure blogger. I still post the thinker-links and the occasional serious bit, but I tend to be funnier than I am poignant, and the funny stuff is fun to write¹.

Anyway, my server has been crushed several times this year², and I’ve found a few simple ways of coping. But first, what does it look like to crush a Dreamhost server?

$ uptime
... load average: 198.75, 201.04, 143.88

That’s a 50x overloaded server, not considering DB or I/O load³. But today’s traffic threw it right off the map, as the box was seeing more than 100 connections per second (compared to the previous max of 10/second).

So how do you pull yourself out from under a good server-kicking?

Step 1 - Pull the plug

It’s simple:

mv site.com site.com.off

You’ll lose a few thousand visitors, but that’s the price you pay for not planning ahead.

Step 2 - Find and cache

Create one directory per busy article, based on the path setup for your site. Dig through your browser cache⁴, and save each busy page at their full path as static html.

So if your hosed page is http://site.com/2007/10/31/funny-ha-ha/, you mkdir -p 2007/10/31/funny-ha-ha/ and add a static html file with the content in it. Disable any other CGI calls on the page (like comments), and add some ads if they’re not there already.

Step 3 - Re-enable site

By this point your server has stopped bleeding processes and has a chance of sustaining some static traffic. Move the disabled site back to its original name, and run top while tailing your server logs looking for errors in your static pages.

Total time to hack-cache-resurrect your site should be no more than 2-3 minutes. And your server should look something like:

... load average: 11.41, 12.50, 24.68

It’s not perfect, but it’s functional.

Step 4 - Clean up

Don’t forget to clean up your static pages when the storm subsides. Remove the static pages, and consider better planning for the next time.

But what about wp-caching?

I’ve used wp-cache (both the plugin and the built-in object cache), and found that they aren’t as effective as simple, static pages. The plugin form of the cache still hits the DB on each page load, and the built-in object cache doesn’t seem to improve things against heavy loads⁵.

(Note: I’m going to give the updated wp-cache plugin another whirl, see if it has improved.)

1. Duh ↩
2. Today is the first time I’ve had to intervene, a 10x increase from the previous largest crushing ↩
3. The server is a capable 4-way system, with a few other semi-busy sites on it, so a normal storm doesn’t phase it ↩
4. You cached the pages, right? ↩
5. I need to measure this, and verify that I’m not missing some configuration ↩

A Capistrano HOWTO for Dreamhost hosted domains. And another, and another.

Tips on running Rails apps on Dreamhost, including tips and corrections to the Dreamhost wiki documentation.