slate blog

In the spirit of KYTCR article by John we’re offering some tips on what we do to manage our install. I’m not going to go into nearly the depth that John has already done and hopefully will continue to do. Why?

• We don’t do back-ups. Before you write to say we’re crazy, all the stuff related to slate is backed up. Just not by us so I can’t tell you anything about it.
• Problem analysis and resolution. This usually consists of some curses (if I’m around), gritting of teeth, whispers of “stupid users,” and eventual elegant solution courtesy of Chris.
• Log rotation. some time goes by “Chris, we might want to reset that production log.” We did try to automate this once but it blew up in our faces.
• Cache. We’re not exactly at a point where we have to be seriously worried about it.

The Hardware Setup
I was sort of surprised to find that slate is running on the smallest server we manage.

• The app server – a 3.2GHz Xeon box with 1GB of RAM running Windows Server 2003. It’s shared with a few low-use RoR apps and a PHP app.
• The database server – Multi-Xeon box with 2GB of RAM. We use Microsoft SQL Server for the DB.

Our Numbers
I made a post on this back on Oct. 4th. In the interest of giving up-to-date numbers I’ve redone them.

• From Oct. 5th to Nov. 4th we served 322,505 pages.
• From one install of slate we push out approx. 71 sites made up of:
  • 3,850 pages
  • 5,674 resources (user uploaded images, documents, etc.)
  • 594 blog entries
  • 39,746 comments with the vast, vast majority being spam

As a comparison, over the same time period the WVU home page had 1.86 million page views. Ok, with that background covered lets get into things we do to manage our install.

The Stack: Apache & Mongrel
We’re using Apache 2.2 with mod_proxy_balancer to proxy requests to a cluster of five Mongrel services to serve slate to the masses. I’ve written about our past experiences so I’m not going to rehash it too much. Nothing has really changed in a year. Suffice it to say we’re happy with the set-up and haven’t looked at anything more exotic. I also posted an article on the balance-manager. I’m not going to share our config but a couple of notes related to how we like to do things:

• ProxyPass is better than RewriteCond and RewriteRule for serving static files. This is just my opinion. One of the great things with Rails is that it forces you into certain directories to deliver static vs. dynamic content. Why double-check?
• Need to do a redirect? Make sure you’ve added it’s own ProxyPass. We require SSL for the slate account login page. So if you request the unencrypted page you get bounced to the encrypted page.
• Discourage access to .svn, .erb, or .rhtml files with DirectoryMatch and FilesMatch. Since our themes are essentially public (for images and styles) and the templates are .rhtml files we’ve made sure to deny access to them. Not allowing access to .svn might be overkill but oh well.

  <DirectoryMatch "\.svn">
    ErrorDocument 403 /404.html
    Order allow,deny
    Deny from all
    Satisfy All
  </DirectoryMatch>

  <FilesMatch "\.rb">
    Order allow,deny
    Deny from all
  </FilesMatch>

  <FilesMatch "\.rhtml">
    Order allow,deny
    Deny from all
  </FilesMatch>

Rubykill: How We Manage Mongrel on Windows
I’ve never really taken the time to learn how to manage a Windows box properly. I’ve always focused strictly on software (e.g. PHP, Apache) and not the OS itself (others manage the OS). So when it became apparent that we were picking up more traffic and Mongrel liked RAM we had to find a solution to restart Mongrels just in case. The quick, dirty, and brute force solution? Rubykill.

Rubykill is just a scheduled task that takes out a Ruby process. We run it five times a night so essentially slate is restarted once a day. The significant downside to this solution is that you’ll get a proxy error for about 30 seconds before the proxy balancing kicks in. It takes about a minute for Mongrel to start back up again. In that time Apache realizes it’s out of commission and works around it.

And, yes, rubykill is overkill.

Working with RedCloth
Way back when I posted an article about slate and RedCloth/Textile. If you’re going to be using RedCloth for your markup and have a number of folks who will be using your system then learn from our experience. Read the article and then come back here for some more tips.

patiently waits

Ok, here you go:

• Change your code markup from one @ sign to two. If you don’t you’ll run into problems with folks trying to put email addresses on one line. It gets really funky. So, Ryan, that’s why you get @something@ in the comments instead of a code tag ;)
• People like dashes. We’ve had a number of folks submit comments to various blog articles and they’ve used dashes (e.g. trying to make an em dash). To RedCloth this means a strike-through and then people get a little huffy when their post has been supposedly “edited/censored.” Just be careful with this. I don’t think we’ve put a “fix” in other than making sure superadmins can edit comments in the next release.
• Use the Textile Editor Helper. Did you think I wouldn’t plug it? Check it out.

Next Article…
Chris will eventually follow this article up with one related to deployment and some of the stuff he’s done to future-proof slate a little. I’m not sure if there’s much more to really cover other than that. Let us know what you think.