Re: Mailing list performance
On Tue, Aug 08, 2000 at 08:30:47AM -0400, Dave Sill wrote: Motonori seems to have thought that the "smtp" service entry in master.cf controlled outgoing concurrency, when, in fact, it controls incoming concurrency. I think still this is not correct. Actually there are two 'smtp', one for incoming (smtpd daemon), one for outgoing (smtp daemon). I think, Monotori was not make any mistakes with this regard. 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. Where such a conclusion come from? The author never mentions about the number of domains in the evaluations. 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. Better you consult the graph's legend and read 'How to read the graphs'. In this regard, 'a' mean, number of message(s) sent after the first dns query. As you see in postfix, it has negative value, so it 'doesn't mean' anything, in this regard. 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). You're right. I just do a little, very unscientific test :-) BTW, if you're right, i.e the evaluation just do single rcpt to deliveries, then I did't see any reason to say that postfix is better than qmail and vice versa. Salam, P.Y. Adi Prasaja
Re: Mailing list performance
"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
Re: Mailing list performance
"David Dyer-Bennet" [EMAIL PROTECTED] wrote: Dave Sill [EMAIL PROTECTED] writes on 4 August 2000 at 09:37:29 -0400 Eval 1 Eval 2 Eval 3 MTA timedns timedns timedns qmail 155 1250 127 1230 127 1235 Postfix184 1375 168 1290 161 1330 exim 645475 161450 157451 SMTPfeed 215610 160442 157461 zmailer 1530 1675 357 1260 360 1300 I read the time on eval 1 for qmail as 20 seconds. Well, maybe 22. There's a very sharp bend in both DNS and SMTP curves at that point, and only completely trivial activity after that. Ah, so you're looking at the time to deliver something like 97-99% of the messages. I'm looking at the 100% times, which tend to be dominated by a couple of slow remote servers. I'd like to see the raw numbers in addition to the graphs. -Dave
Re: Mailing list performance
"P.Y. Adi Prasaja" [EMAIL PROTECTED] wrote: On Thu, Aug 03, 2000 at 08:14:32AM -0400, Dave Sill wrote: He apparently confused incoming concurrency with outgoing concurrency. Luckily, Postfix defaults to 50, so the results are still valid. Then you wrong either :-) No, I'm not wrong. If you're going to "correct" someone, please check your facts first. From http://postfix.cloud9.net/rate.html: The default_process_limit parameter (default: 50) gives direct control over inbound and outbound delivery rates. This parameter controls the number of concurrent processes that implement a Postfix service (smtp client, smtp server, local delivery, etc.) It says 50, not 10. Default _maximum_ concurrency is 10, Perhaps you're thinking of default_destination_concurrency_limit? That's the *per destination* limit, not the overall concurrency limit. Even though the author increase the number at master.cf, say 1000 (as I said that it has nothing todo with concurrency, neither incoming nor outgoing, beside the fact that there are no _incoming/outgoing_ concurrency in postfix, the number is for differrent purpose). then the concurrency still be limited to 10 and will started at 5, etc... etc... 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: From http://postfix.cloud9.net/rate.html: You can override [default_process_limit] for specific Postfix daemons by editing the master.cf file. For example, if you do not wish to receive 50 SMTP messages at the same time, you could specify: # == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (50) # == . . . smtp inet n - - - 5 smtpd . . . -Dave
Re: Mailing list performance
On Wed, Aug 02, 2000 at 08:32:37PM -0600, Irwan Hadi wrote: I saw, at least at evaluation 3, postfix beat qmail ;) BTW, still don't know how about exact configuration that the author's using while doing the experiments. If this information could be gathered from: http://www.kyoto.wide.ad.jp/mta/eval1/eoperation.html then one can make a conclusion that the authors no nothing about postfix. /etc/postfix/master.cf has nothing todo with concurrency control in postfix, at least if he think that it has the same fashion as qmail. Salam, P.Y. Adi Prasaja
Re: Mailing list performance
Irwan Hadi [EMAIL PROTECTED] wrote: http://www.kyoto.wide.ad.jp/mta/eval1/eindex.html I saw, at least at evaluation 3, postfix beat qmail ;) Check again. qmail won all three tests. In Evaluation 3, qmail finished in ~125 seconds, and Postfix took over 150 seconds--next to last place. So where's that 3x speed Postfix has over qmail? -Dave
Re: Mailing list performance
"P.Y. Adi Prasaja" [EMAIL PROTECTED] wrote: If this information could be gathered from: http://www.kyoto.wide.ad.jp/mta/eval1/eoperation.html then one can make a conclusion that the authors no nothing about postfix. /etc/postfix/master.cf has nothing todo with concurrency control in postfix, at least if he think that it has the same fashion as qmail. He apparently confused incoming concurrency with outgoing concurrency. Luckily, Postfix defaults to 50, so the results are still valid. -Dave
Re: Mailing list performance
On Thu, Aug 03, 2000 at 08:14:32AM -0400, Dave Sill wrote: then one can make a conclusion that the authors no nothing about postfix. /etc/postfix/master.cf has nothing todo with concurrency control in postfix, at least if he think that it has the same fashion as qmail. He apparently confused incoming concurrency with outgoing concurrency. Luckily, Postfix defaults to 50, so the results are still valid. Then you wrong either :-) Default _maximum_ concurrency is 10, but postfix will use 'slow start' strategy, then the concurrency will started at 5, it would be increased, slowly, as long as the remote host happily accept (all of these are configurable). Even though the author increase the number at master.cf, say 1000 (as I said that it has nothing todo with concurrency, neither incoming nor outgoing, beside the fact that there are no _incoming/outgoing_ concurrency in postfix, the number is for differrent purpose). then the concurrency still be limited to 10 and will started at 5, etc... etc... Salam, P.Y. Adi Prasaja
Re: Mailing list performance
Fernando Almeida [EMAIL PROTECTED] wrote: Irwan Hadi wrote: At 08:45 PM 8/1/00 -0300, you wrote: Im setting a mailing list system that will require a VERY good performance. After search for a lot of options, Ive decided to use qmail because I think it is the most quick and configurable MTA. you wrong. postfix (Www.postfix.org) is 3 times faster then qmail. You wrong. See: http://www.kyoto.wide.ad.jp/mta/eval1/ (Japanese text, but the graphics are labeled in English.) Ive just read the postfix documentation, and I would like to know about how secure it is. I don't think it's quite as secure as qmail, but it's way better than Sendmail. -Dave
Re: Mailing list performance
Dave Sill [EMAIL PROTECTED] writes on 2 August 2000 at 10:14:56 -0400 http://www.kyoto.wide.ad.jp/mta/eval1/ Just noticed that this is now available in English: http://www.kyoto.wide.ad.jp/mta/eval1/eindex.html His methodology looks reasonably sound, now that I can read the description of it. And he seems entirely aware of the shortcomings, which leads me to trust his judgement on other matters as well. Looks like qmail took 20 seconds and sendmail took 1750 seconds to deliver his test load. Not surprising! (uncached case) Also note that in the cached case postfix appears to beat qmail at delivering all the mail, at least on one graph. However, did people notice that sendmail actually did *fewer* DNS queries? I had understood that for total bandwidth use, qmail won over sendmail partly for doing less DNS traffic, but this doesn't seem to be the case in this study. And unfortunately he only counts syn/fin and dns packets, there's nothing that directly records bandwidth used. I guess we can make assumptions about data transmitted per SMTP connection to calculate bandwidth, and not be too far off. His graphs seem to show all mailers making essentially the same number of SMTP connections, so it sounds like his address mix doesn't allow for much multi-rcpt. (postfix took 30 seconds, exim 500, zmailer I can't tell. Am I reading the graphs wrong? Zmailer shows increasing count of DNS queries off to the end of the map, but no increase in SMTP syn or fin. Now I'm confused.) -- Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
Re: Mailing list performance
Fernando Almeida [EMAIL PROTECTED] wrote: Im wondering what can I change to improve the performance of my mailing list, I already read the documentation and found a lot of thinks like the number of paralell proccess and other things. I really need a great performance in this mailing list, so I would like to know some tips and the best mailing list manager to use. I would like to know also some statistics of performance in mailing list using qmail Use dnscache (from djbdns). Can you tell about your lists and the configuration of the hardware that will be serving them? Does the h/w exist, or do you have a budget? How big are the lists? Where are the subscribers? How big are the messages? How quickly do you need to deliver them? Will you be using ezmlm or some other list manager? -Dave
Re: Mailing list performance
At 10:14 AM 8/2/00 -0400, Dave Sill wrote: http://www.kyoto.wide.ad.jp/mta/eval1/ Just noticed that this is now available in English: http://www.kyoto.wide.ad.jp/mta/eval1/eindex.html -Dave I saw, at least at evaluation 3, postfix beat qmail ;)
Re: Mailing list performance question
Fernando Costa de Almeida [EMAIL PROTECTED] writes on 28 July 2000 at 18:04:35 -0300 Im wondering if there is a list manager that deliveries emails according with the domain, in a single smtp connection. Let me explain better: Im trying to implement a newsletter mail system, so the same mesg will have to be sent to a lot of users (maybe in the same domain, may be not). Its intutive that the best way is to send the body one time for a lot of rcpt`s, instead a lot of emails. This feature, plus some parallelism in this proccess could make the proccess very fast. Before try to write something to do this, I would like to know if someone knows a tool that does the service for me. :-) The choice for qmail as the MTA is based in your efficiency. I hope that I was clear. Qmail won't do this for you. Qmail doesn't do multi-rcpt mails. However, while it's intuitive, it's not always *right* that this is a win. We've just had *another* unpleasant round of this discussion (it comes up frequently) so I won't start it up again if I can help it. Qmail with ezmlm+idx is *very* good for mailing lists, including newsletters. It automates bounce handling better than anything else because it uses "VERP", so that any bounce at all back to the mailing list an be accurately and automatically recognized as to what user caused it. And it delivers the mails very fast. On my otherwise very lightly loaded system, there's a monthly newsletter that gets sent to more than 43000 addresses (last I looked). The system is a Pentium 166 with 96 meg of ram, and the net connectivity is 768k household-level DSL. The last issue of that newsletter was about 33k, and as I say goes to over 43000 addresses. I don't really notice when it goes out, and the mail log for the next day isn't any bigger than normal. (The log two days later is big again with the bounces :-) ). -- Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
