Victor.Duchovnimorganstanley.com
Date: Wed Jun 11 2003 - 21:02:06 CDT

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

On Wed, 11 Jun 2003, Leandro Santi wrote:

> 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);

Yes, this throttles the process creation rate and so also the message
throughput.

>
> 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.

No. In this case the throughput limit is P*100/N*timeout, where P is the
process limit and N is the number of maps that the process opens during
its lifetime. Each of P processes delivers 100 messages per N*timeout
interval.

> 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).
>

No, there is no problem in the delayed connection scenario unless the
process limit is very low.

--
        Viktor.

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