Subject: Re: moving to a git-backed wiki

From: Joey Hess <[email-masked]>
Date: Fri, 4 Feb 2011 10:34:21 -0400

Jeff King wrote:
> If it sounds like I'm handwaving away scalability problems, I am. I'd be
> curious to see some performance numbers for gollum or ikiwiki versus
> more traditional wiki formats.

Ikiwiki builds static pages, this tends to mean it doesn't have
performance, because there is little more to perform than
httpd < file > network :)
So I've routinely had ikiwiki sites slashdotted, and not noticed.

Ikiwiki is not enormously fast in the rare cases when it does have to
run as a CGI, but little of that has to do with git. About the worst
case is that saving a page edit leads to a git commit -- if git
decides to gc the repository right then, it could make the save stall
for a while. There are easy ways to avoid that. (ie, git gc in cron job)
In general, though ikiwiki as a CGI is fast enough to not be annoying -- 
although it won't scale to a site the size of wikipedia.

Since I'm lazy, ikiwiki does not include a history or diff viewer. It
just points off to gitweb or a similar tool. As you say, gitweb can be
fast enough, and really most wiki users do read their current content,
or maybe make an edit; digging in the history is comparatively rare.
And once users realize the wiki is in git, they can use gitk to dig in
the history without using any server resources. :)

The feature I like best with using git for a wiki (besides ease of
branching) is that it can actually make a legitimate use of the
woefully underused git push over git:// feature. Ikiwiki can be
configured to check such pushes, running via the pre-receive hook. This
allows it to limit the changes that can be pushed anonymously to changes
that could be made using the web interface. So if you've chosen to lock
some pages, or virus filter attachments, or whatever, in the web side of
the wiki, that all applies to the anonymous git pushes too. Details at
<http://ikiwiki.info/tips/untrusted_git_push/>

-- 
see shy jo