[typo] Slow spam checking makes Baby Jesus cry

Piers Cawley pdcawley at bofh.org.uk
Sun Aug 20 16:02:03 EDT 2006


RBL spam checks on the machine my blog is running on are slower than a
very slow thing on a slow day. Which does bad things, because a
fastcgi process that's tied up doing dns lookups and the like is a
fastcgi process that can't let the user know that their comment has
been accepted and is being checked for spam. Which means they hit
submit again. And again. And again. And who can blame them?

It's also a fastcgi process that can't serve any requests. And fastcgi
processes that can't serve requests are just the sort of thing that
hosting services resource limiters don't like to see.

So, we need some way of getting back to the user and accepting the
next request ASAP. 

My current thinking is to tweak the behaviour of
ContentState::Undefined so that instead of doing the spam check before
saving the content and then changing the feedback state, it will have
an after_save that looks something like:

   def after_save(content)
     t = Thread.new(content) do |feedback|
       classify(feedback)
       feedback.save
     end
     t.join if defined? $TESTING
   end

The catch is, IPSocket.getaddress, which is what we use for DNS
lookups, appears to be be a blocking call, which with the nature of
Ruby threads, means it'll *still* hold up processing during the
lookup.

Thoughts?

-- 
Piers Cawley <pdcawley at bofh.org.uk>
http://www.bofh.org.uk/


More information about the Typo-list mailing list