spf-discuss
[Top] [All Lists]

Re: Performance issues

2004-02-17 15:53:35
On Tue, 2004-02-17 at 15:03, Hector Santos wrote:
Theo, I don't wish to dive much of this detail discussion that I don't think
is revalent, but just to say, that unless your multi-threaded application is
finely tuned, I mean completely optimized for async I/O, makes extensive use
of kernel wait events, minimal exclusive locks (critical sections,
reader/grabbers, etc),  your default thread time slicing is at the mercy of
the  OS scheduler and the default and minimum quantum time is 10ms (13-15ms
in multi-processors).  That quantum time is only improved by finely tuned
asynchronous I/O but yet kernel synchronized threaded applications.

Your argument says that it would take a lot of fine tuning to get
locking and threading and async I/O to run that fast...  SMTP has been
around since 1982, it is reasonable to expect that MTA authors in this
day in age "finely tune" their code.

It is not just about what individual thread can handle efficiency, but that
there are other details not considered in your message; client/server
reaction time and many other issues.  Just consider worker thread queuing
designs, so if X worker threads are designated for receiving,  when one
thread is in session, that is one less thread available regardless of how
long or little it takes, i.e., there is no unlimited # of threads.

Sounds like you have pinpointed threads as a limited resource.  Try not
using them -- works well for countless server implementations.

So yes, there will be lots of idle time, but that is only because of the
total time between a client/server.   No matter how fast a thread can run,
it is still limited by how fast the client is talking and reacting to the
server.   Understand?

Actually, I don't understand.  We were talking about serving SMTP
sessions and then the conversation shifted to Async I/O, threads, kernel
scheduling quantums, etc.  Granted all those things are important, but
they are implementation details.

It seems that you have equated each session (and their "reactions" with
an individual thread or shared worker thread).  While that is one of my
least favorite scalable design patterns, if that works for you that's
great.  There are many Internet server implementations that take that
approach with great success.  Personally, I find that a "thread" is a
very heavy weight concept to be associated with something as
light-weight as an SMTP session.

Building an Internet server that serves many thousands of concurrent
connections is well documented.  There are countless open-source and
proprietary examples.  Arguing over implementation details isn't
something I'm interested in doing, it is a beaten horse summed up nicely
on Dan Kegel's site:

http://www.kegel.com/c10k.html

The total transaction time in short is:

    ttt =   CT + ST

where

CT is the client time to issue request (including reacting to responses),
and

ST is the server request processing time

from start to finish.

We agree on the definition of "total transaction time".  We don't agree
on its importance.  If a transaction takes 1 second or 10 seconds, it
doesn't matter.  MTA->MTA deliveries happen behind-the-scenes anyway. 
As long as I can ensure that the transaction time doesn't exceed X and
that my throughput is not effected, then all is well.

Now, what I am more interested in improving are the possible delay factors
within ST which are "external" to the SMTP processing itself or required
server-side dependendencies (i.e, user look ups, etc).

These external processing is mostly related to DNS and by emperical data,
this is a large part of the overhead time largely due to failed look ups.
DNS client caching helps tremendously when there is many hits by the same
system within a short relative period.    If you have any tips you can
provide on how to best "optimize" a DNS server or DNS client for better
failed responses, I would love to hear them.

Yes, much of this ST time is can be eliminated by removing other testing
methods, but I don't think we are there yet with SPF and compared to RBL,
both serve by providing different sets of information.  Since SPF does not
resolve the compliant SPF spammer,  thus RBL will still need to be available
to report the compliant SPF spammer as an abusive system.

I don't think removing the methods is prudent at this point.  I was
arguing that performing SPF checks (assuming you cache records) is
better to do _before_ DNS RBL as the failure could prevent looking up
the host in DNS RBL.

I believe that you would net less DNS queries if SPF was performed first
(assuming it is cached).  Though I'd be happy to see hard evidence to
the contrary.

Finally, there is no way on earth we will remove our final test of the
suite - CBV which does the call back verification.  This is proven without a
doubt, to be a great defense against spoofed return path addresses, not just
spoofed return path domains as LMAP based solutions can only address.  But
the goal of even including the other first level test, is to remove any
overhead/redundancy or need to perform a CBV test.


I don't really have much of an opinion on CBVs.  I've built out
environments with them and without them.  But as a devil's advocate:

Protecting yourself at the expensive of the innocent is a dangerous
game.  CBV is cost-shifting -- plain an simple.  While I agree that it
is an effective means for rejecting fraudulent mail, it is considered by
many anti-spam advocates to be as evil as DSNs.

It is particularly dangerous if you run a high performance system.  A
multitude of connections from around the world to a system running CBV
all using envelope senders at the same victim domain will cause that CBV
system to DoS the victim domain's MX.

Just like the ancient DSN, it is a flawed idea whose implementation is
prone to severe abuse.

In any case, we made our wcSAP suite of anti-spam methods flexible enough
for admins to choose and decide for themselves.

Choice is good.

I'm happy to put this thread to rest.  If you want to discuss
performance details in general, I'd be happy to discuss it off-list.  It
has little to do with SPF at this point.

I would, however, be very interested in any information on the query
traffic patterns when performing SPF before DNS RBL as opposed to doing
it after.  My hunch is SPF-first is better, but I'd be happy to change
my outlook based on evidence.

-- 
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on earth



<Prev in Thread] Current Thread [Next in Thread>