Xblog

Instead of doing that, I noticed that despite updates to the software on my system, I was still running an old version of Typo. It turns out you have to explicitly upgrade each deployment of Typo (not necessarily a bad thing). As always, there is an easy way to do this…. and it didn’t work for me (probably PEBKAC, but nonetheless frustrating). Anyway, after several false starts, I managed to upgrade to Typo 4.1.1.

There are a number of improvements that have come with upgrade that look to make life better on xblog. Oddly though, the new theming seems to be completely broken –except for on Safari. Yup, if you are looking at this with anything other than Safari (actually, I haven’t tested with Opera yet), you are probably seeing a pretty ugly looking site. Firefox shows the site as broken on Linux, Mac, and Windows. IE7 looks the same.

I haven’t diagnosed the how and the why behind all this, because I’ve been stunned by the downright awesomeness of this. The problem seems likely related to stylesheets, but for the life of me I am trying to figure out what is so different about my setup from a typical Typo configuration, and more importantly just look in awe at Safari.

First of all, Typo filtering just doesn’t seem to work how I’d expect it to. It may all be user error, as I haven’t looked at the code for it. I’ll look at it more closely in the near future, but for now impression is that it doesn’t work the way it needs to to be effective.

The Akismet support for Typo also seems to be lacking. Enabling it mostly seemed to result in me getting timeouts. I went to look at the Typo site to see how other people were tackling this and discovered… the site was temporarily down. Nice that.

What blows me away is that Typo’s “bulk operations” is still tied to the same synchronous “wait for it to complete or we’ll time out” interface as everything else. What’s clearly called for here is some primitive queuing up of bulk tasks. I’m still learning Rails, but my bet is Rails doesn’t have an easy way to do such a thing (although it seems like it’d be easy to do in Ruby).

Ultimately, I ended up going with the tried and true approach: just blocking port 80 access to IP’s and subnets that were clearly running comment bots. Not an ideal solution if you have a broad audience, but given that I probably have a typical audience of a handful of people, the odds of me accidentally knocking off someone who’d actually read my blog are slim to none. Since I started firewalling off people’s IP’s, the torrent of comment spam that I normally see has diminished to a perfectly manageable level.

So keep that in mind: firewalls are your best frend when it comes to blocking comment spam.

I had noticed that my blog was getting quite slow and handling updates, and it wasn’t clear to me why. I am particularly sensitive to efficiency issues, because I run this whole thing inside a User Mode Linux instance, which imposes it’s own inefficiencies on pretty much all aspects of the Linux kernel. So I generally have to be fairly careful to tune everything I run inside it to minimize kernel involvement. I was all ready to blame UML again until I looked at what was going on with the instance: it was swapping like crazy.

Some peaking around in the system showed working set sizes for my Ruby FastCGI processes in the 35MB-50MB range (very bad considering my instance only has 64MB of RAM allocated for it) –that’s the kind of footprint that makes you start to think of J2SE/EE! To get an idea of how inefficient that is, Postgres’s working set size for handling this puny blog is about 4-5MB.

So far, I’ve been able to get back to some kind of decent performance by trimming my FastCGI process count down to one (which has some unfortunate side effects, but none as unfortunate as having 20-30MB of memory constantly swapping).

This tweaks my curiosity as to what’s going on under the covers, and how much of the overhead is Ruby, how much is Rails, and how much is Typo.

It’s a trivial bit of code:

require 'postgres'

sequences = [
  'blacklist_patterns', 'blogs', 'categories',
  'contents', 'page_caches', 'pings',
  'redirects', 'resources', 'sessions',
  'sidebars', 'tags', 'text_filters',
  'triggers', 'users'
]

def fixSequence(db,tableName)
  results = db.query("select max(id) from #{tableName}")
  max_id = results.first.first
  if max_id then 
    db.exec("select setval('#{tableName}_id_seq'::text,#{max_id});").clear
  end
end

db = PGconn.connect("localhost", 5432)
sequences.each {|sequence| fixSequence(db,sequence)}
db.close()

So far, my first impression is that Ruby tries to be like Smalltalk, but is Perlish enough to fall short IMHO. Of course, I hardly know the language yet, so there may be a more elegant way to do things that I have yet to uncover. In particular, I’m wondering why the True and False classes don’t have “ifTrue:ifFalse” type methods that take blocks as arugments. Seems like an obvious “nice to have”. IIRC it’s possible to add methods to existing classes, so maybe I can do this to keep the Smalltalk cravings to a minimum.