[typo] Slow spam checking makes Baby Jesus cry
pdcawley at bofh.org.uk
Mon Aug 21 02:44:01 EDT 2006
Dominic Mitchell <dom at happygiraffe.net> writes:
> Piers Cawley wrote:
>> Piers Cawley <pdcawley at bofh.org.uk> writes:
>>> Piers Cawley <pdcawley at bofh.org.uk> writes:
>>>> 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
>>> Hmm... resolv.rb may be our friend. And (bonus points!) it's in the
>>> standard library.
>> And, following further work on using threads, I'd just like to say
>> that threading is weird and is currently doing my head in. Background
>> classification sort of works, but only very approximately.
> Would it not be possible to take the same approach as mod_perl and
> schedule some code to run immediately after the current request, but
> before the next one (a cleanup handler)? It would still mean that
> particular fastcgi process was unavailable, but it would mean that you
> could return to the user quicker.
Sadly not. Some of the spam checks I've seen in my logs have taken the
best part of a minute. Tie up a couple of dispatchers like that and
your performance is screwed.
> Unfortunately, a quick look in railties at the dispatcher shows that
> rails doesn't offer anything like this. Damn.
Monkey patching the dispatcher to allow it isn't exactly hard. But see above.
Piers Cawley <pdcawley at bofh.org.uk>
More information about the Typo-list