from __future__ import *

Since the svnsync tool in Subversion 1.4 still lacks documentation, here's a quick example to get you started with it:

$ svnadmin create svn.mochikit.com
$ echo '#!/bin/sh' > svn.mochikit.com/hooks/pre-revprop-change
$ chmod +x svn.mochikit.com/hooks/pre-revprop-change
$ svnsync init file://$PWD/svn.mochikit.com http://svn.mochikit.com/
$ svnsync sync file://$PWD/svn.mochikit.com

The example performs the following tasks:

• Creates a new local repository named svn.mochikit.com
• Adds a trivial pre-revprop-change hook to the repository (required for svnsync)
• Initializes the svn.mochikit.com repository to be a mirror of http://svn.mochikit.com/
• Synchronizes the svn.mochikit.com repository with its initialized source

Note that this is point-in-time synchronization. To keep an up to date mirror you'll have to run svnsync sync on a regular basis (e.g. by cron job or post-commit hook).

If you're looking for an especially easy to install set of svn binaries for Mac OS X, I recommend Martin Ott's (of SubEthaEdit fame) build. I've been using it on all of my Macs for quite some time with no issues. Much less hassle than building it myself or using MacPorts (previously known as DarwinPorts).

A few weeks ago in Reverse Proxy Roundup I was evaluating reverse HTTP proxy solutions. At the time I had settled on Pound, but frankly it wasn't good enough for the load I expected it to handle. Additionally, spawning so many threads used far more RAM and CPU than it should've.

Not long after I wrote that post, a friend of mine pointed me at nginx. nginx is an extremely high performance HTTP server that offers reverse proxying, FastCGI, SSL, and even IMAP/POP3 proxying.

I have had precisely zero problems with nginx so far after about 5 weeks and hundreds of millions of proxied requests. Forget about lighttpd, nginx uses less memory, doesn't leak, and has higher performance (in my FreeBSD configuration, anyway).

The reason I didn't blog about it sooner is that the project is Russian and so was a large majority of its documentation at the time. With the 0.4 release, there's a much more complete draft of the English documentation available. Check it out; your high traffic servers will thank you for it.

The first line of defense in scaling out a web solution is a load balancer, often implemented as a HTTP reverse proxy. In my particular situation, I wanted to be able to load balance based on HTTP headers (Host is a must, URL is a bonus) on a FreeBSD platform.

Apache 2.0 + mod_proxy

Pros:

We were already running Apache, so it was an obvious initial solution to the problem. Not too bad to configure, well documented, and pretty stable. It served us well for quite some time.

Cons:

The prefork MPM is definitely not ideal for this purpose and doesn't give us the scalability we want. Screwing around with other MPMs was not ideal because Apache is also doing other things that we didn't want to disturb. Maintaining a separately configured installation just for proxying isn't a good solution. The thread-using MPMs would only be a small win, anyway.

LightTPD

Pros:

Easy enough to configure, supports all of the features we need, pretty good performance and scalability. Single process event-driven model that can use kqueue.

Cons:

Spotty documentation. Totally bizarre configuration language. Not terribly mature compared to other solutions. Lots of bugs. The current version (1.4.11) leaks memory like a sieve (#758), so it's unfortunately not an option at this point.

Pound

Pros:

Solid documentation (but only in man page format). All of the features we need, not a whole lot of other junk. Good track record. This is what we're currently using for now, but it's no permanent solution. Better than Apache, and it doesn't seem to leak RAM.

Cons:

Uses LOTS of threads. That means lots of RAM, limited scalability and performance. Documentation is only available as a man page, had to install it to really evaluate it.

The other solutions I looked into, but didn't end up trying were

Squid:

Way too complicated. Too hard to figure out how to get it to do what we wanted to. Might be a good solution though, so I'll probably look into it again.

Perlbal:

No usable docs. FreeBSD port exists, but sucks (no rc file, no sample config). Couldn't figure out how to get it to reverse proxy with the features that I needed. Written in Perl, which I do grok, but don't like hacking on.

HAProxy:

Looks awesome, but doesn't have the features we need. Seems to only be able to do IP based load balancing, not by headers. More than just a TCP proxy, but not enough of a HTTP proxy.

Balance:

Just a TCP proxy.

Pen:

Just a TCP proxy.

We're currently experimenting with various optimization techniques for our databases using PostgreSQL's features, and we've become quite interested in the Table Partitioning in PostgreSQL 8.1. Bizgres has this feature now (amongst others that will likely benefit our app) in its 0.7 release, so I decided to give it a whirl.

Installing Bizgres 0.7 on Mac OS X is easy enough, but it loses a few points (no big deal, it's beta):

• The installer doesn't use Apple's installer, it uses some InstallAnywhere crap that I don't really trust
• The installer is probably one of the ugliest things I have ever seen on Mac OS X outside of perversiontracker
• It throws a readline library in a Fink-owned location if it's not already there (install_name_tool, anyone?!)
• It doesn't install any sort of preference pane, StartupItem, or GUI tools at all
• The demos are there, but they're sitting in tar files... wtf?

Installing on FreeBSD er.. loses even more points. It's not a supported platform yet, so that's to be expected. The build process depends on a suite of bash scripts to set some environment variables, and ant to do the build. Autoconf happens somewhere too, but that's not invoked directly. The problems here are:

• Bash isn't the default shell in FreeBSD, and isn't even normally installed (unless you did it yourself)

• The bash scripts assume /bin/bash (where it's /usr/local/bin/bash on FreeBSD)

• The Ant build script, common.xml:

  • Needs OS-specific incantations
  • Assumes make is GNU make
  • Assumes bash is at /bin/bash (even though it checks for its presence anywhere in $PATH!)

• Oh, and it needs Java for Ant:

  Java Is A Royal Pain In The Ass On FreeBSD (and installing it is beyond the scope of this post).

So anyway, I fixed those things and made a patch. Here's how you could build and install with it:

• Download the 0.7 source tarball

• Do this:

  cd bizgres
  curl -s http://redivi.com/~bob/bizgres-0_7_4-FreeBSD-1.patch | patch -u -p0
  su
  bash
  source source-before-build.sh
  ant -Ddebug=false -DinstallRoot=/usr/local/bizgres -DdevoBuild=true install
  exit
  exit
  

This will install bizgres to /usr/local/bizgres-0_7_4. It's not going to make any rc scripts for you, but they can be trivially adapted from the PostgreSQL port.

Note that:

• This is the first time I've ever attempted to port something to FreeBSD (though I do have extensive Mac OS X experience)
• Bizgres 0.7 is beta software
• This is largely untested
• FreeBSD is not a supported platform (by them, or me)

If this causes you to lose all of your data, first, make sure that you weren't using MySQL. If you were indeed using Bizgres on FreeBSD, then blame yourself for not listening to the above.

UPDATE:

Changed the URL of the patch to one that compiles with OpenSSL support by default. To add OpenSSL support to an already patched source (or to JUST add OpenSSL support to unpatched source), use the following:

http://redivi.com/~bob/bizgres-0_7_4-OpenSSL.patch

/usr/ports/databases/postgresql-contrib comes with the very useful (until 8.1, anyway) pg_autovacuum daemon, but no rc script. Here's one I whipped up:

/usr/local/etc/rc.d/019.pg_autovacuum.sh

#!/bin/sh
#
# PROVIDE: pg_autovacuum
# REQUIRE: postgresql
# KEYWORD: FreeBSD shutdown

# Add the following line to /etc/rc.conf to enable `pg_autovacuum':
#
# pg_autovacuum_enable="YES"
#
#

. /etc/rc.subr


pg_autovacuum_enable=${pg_autovacuum_enable:-"NO"}
pg_autovacuum_flags=${pg_autovacuum_flags:-"-v 300 -V 0.5"}

name=pg_autovacuum
rcvar=`set_rcvar`
command=/usr/local/bin/pg_autovacuum
load_rc_config ${name}
command_args="-D ${pg_autovacuum_flags}"
pg_autovacuum_user=pgsql

run_rc_command "$1"

I did submit a PR with this by way of send-pr, but it doesn't seem to have ended up in the PR repository. I'm not sure what to do about that, as it's the recommended way to submit PRs!