"P.Y. Adi Prasaja" <[EMAIL PROTECTED]> wrote:
>Here is your previous post:
>
>> He apparently confused incoming concurrency with outgoing
>> concurrency.
>
>What are you trying to say in this regard?
Motonori seems to have thought that the "smtp" service entry in
master.cf controlled outgoing concurrency, when, in fact, it controls
incoming concurrency.
>> Perhaps you're thinking of default_destination_concurrency_limit?
>> That's the *per destination* limit, not the overall concurrency limit.
>
>Yes. And seems to me that you pretend to that this would not give any
>impact to the measurements...
It could be a factor if any of the test addresses had duplicate
hostnames. Since they were of the form nobody@FQDN, they were
apparently all unique.
>> Either you're wrong or the documentation on the web is wrong. I don't
>> care enough to determine which is the case. Here is what the web docs
>> say:
>
>No. The docs is minimum, but it isn't wrong.
>If there is no such a limitation in qmail, why should one pretend
>to that there is no such a limitation in other MTA (postfix) too?
I'm not "pretending" anything.
>Once again, if you would like to see the comparisson numbers that
>author gives to us, just see at the linear equation from each graph.
>You would see that postfix beat qmail just for about 1 msg/second
>rate in 2nd and 3th evaluation (this fact is unsignificant, for me at
>least).
Firstly, those rates are for DNS queries, not SMTP deliveries. Second,
a steeper slope doesn't necessarily mean it's faster. The equation is:
y = N x + a
and the "a" can be a significant factor.
>Anyway, if the number of process_limit is increased, say 120,
>with the same condition (environment, machine, etc.), should qmail a
>lot faster than postfix because of its great efficiency in resources
>using by qmail compares to postfix (yes, I didn't talk about the
>whole results, it's about 'internal processing').
Perhaps...that hasn't been proven in a published test, to my
knowledge. I'd also like to see the effect of running a local
dns cache (both djbdns and BIND).
-Dave
