Matt Kettler wrote:
> Second, converting to spamc/spamd would be SLOWER for a MimeDefang
> setup, not faster.

eh... depends on what else MIMEDefang is doing...
 
> MimeDefang calls the SpamAssassin perl API's directly, a method that
> is faster than using spamc/spamd, but is only usable by tools written
> in perl. 
> 
> spamc/spamd is faster than calling the "spamassassin" command-line
> script, but not faster than directly loading the API's.

SpamAssassin memory is frequently a bottleneck.

To use a military analogy:

MIMEDefang threads are like infantry.  SpamAssassin objects are like tanks.

I'm sure every infantryman would love to drive around their own tank.  But that 
would use a *lot* of gas.  The infantryman would say "but this is faster."  But 
tell that to the supply sergeant who's trying to supply the division :)

Another option is to have the tanks nearby, in easy call range of the infantry 
squad.  Much of the time the infantry will be able to handle the enemy 
themselves.  When they need a tank, they can radio for one - they'll have to 
wait a bit, but the benefit is that you can have a LOT more infantry this way 
and still not run out of gas.

The MIMEDefang analogy of this is as follows:

A typical MIMEDefang setup might have ten MIMEDefang threads, each with its own 
SpamAssassin object.

Suppose you have a lot of custom-/third-party-code to deal with various kinds 
of bogeys.  You might reject email that fails a clamav scan, for example.  Or 
you might reject email that has a From: header of a nonexistent address at your 
domain (all of which can be done in MIMEDefang.)  In this sense the MIMEDefang 
thread is capable of eliminating the email itself, without an expensive 
SpamAssassin call.  Of ten SpamAssassin objects, maybe seven might be active at 
any given time.

Having a Perl implementation of spamc would allow this server to have seven 
spamd threads running.  In the space saved by the "extra" three idle 
SpamAssassin objects, you could run as many as a hundred MIMEDefang threads.  
This allows much more throughput, at the cost of any particular individual 
thread running a little slower.

Matthew.van.Eerde (at) hbinc.com                 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com         Software Engineer
perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg," 

Reply via email to