From: Leandro Santi (lesantiuolsinectis.com.ar)
Date: Wed Jun 11 2003 - 20:00:52 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Wed, Jun 11, 2003, Victor.Duchovnimorganstanley.com wrote:
> > > In the case of the "smtpd" and "cleanup" daemons each daemon processes 100
> > > (default value of the max_use configuration parameter) messages and exits.
> > > This means that for each hundred messages delivered master needs to spawn
> > > 100 cleanup daemons and 100 smtpd daemons.
> >
> > Thats the worst case behavior (ie when those messages are sent in a very
> > short time interval).
> >
>
> With a connection timeout 10s per map and say 2 maps, one gets a maximum
> MTA throughput of 5msgs/sec. This is too low for the traffic handled by my
> machines. Yes, since this is a throughput issue, it is only seen under
> high load. People who redundant backend databases would typically be
> interested in performance under high load...
>
> ...
>
> Great, please test to make sure that listing a non-responding IP as the
> first server indeed does not limit the system to 100/N*timeout messages
> per second where N==max{cleanup,smtpd}(number of MySQL connections per
> daemon).

Ok. First let me see if I understand clearly. With my current solution
(ie deterministic round robin), if I list a nonresponding IP as the
first server, then I can only hope to receive (100/N*timeout) messages
per second (I guess 100 is the default maximum number of spawned
smtpd procs) *if* one of the following is true:
                    
(a) The process blindly connects to the MySQL backend at map
initialization time (thus each process'll wait N*timeout seconds) (BTW
this is not the behavior of dict_mysql nor my patched version);

or
        
(b) The process connects to the backend when the first query comes in
*and* theres at least one query per message for each of the N
connections.

The part I don't get is: after the 100 smtpd-cleanup instances are done
with its first message, the connections are already established, so the
throughput will improve, because they won't have to timeout to the first
nonresponding IP again for some time (ie until max_use is hit).

So, if I understood, (100/N*timeout) is actually transient behavior (ie
temporary). If this is the case, then yes, maybe it'd be better to toss
a coin at connection-setup time WRT throughput (I've already understood
the other benefit of the coin approach: its easier to implement, and
the Postfix system will "naturally" discover an overworked MySQL backend
because of its greater latencies).

Thanks,
Leandro.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]