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
On Fri, Aug 04, 2000 at 07:58:20AM -0400, Dave Sill wrote: > No, I'm not wrong. If you're going to "correct" someone, please check > your facts first. oh .. well ... Here is your previous post: > He apparently confused incoming concurrency with outgoing > concurrency. What are you trying to say in this regard? > 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... > 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? 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). 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'). Salam, P.Y. Adi Prasaja
Re: Mailing list performance
Dave Sill <[EMAIL PROTECTED]> writes on 4 August 2000 at 09:37:29 -0400 > "David Dyer-Bennet" <[EMAIL PROTECTED]> wrote: > > >Dave Sill <[EMAIL PROTECTED]> writes on 2 August 2000 at 10:14:56 -0400 > > > > > > 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) > > I don't see where you got 20 seconds. Here's the results in tabular > form--numbers are all APPROXIMATE since I'm reading them from the > graphs (the individual results by implementation): > > 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. I do see that the DNS answer curve is measurable separated from the DNS request curve; but the SMTP lines don't appear to change after that, so whatever DNS is doing, delivery has completed. > >Also note that in the cached case postfix appears to beat qmail at > >delivering all the mail, at least on one graph. > > I don't see that. Well, maybe not, the SMTP fin line is separated a bit from the syn line which the computed line is based on. > >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. > > Yeah, that suprised me, too. Exim wins the prize for DNS frugality, > though. > > >(postfix took 30 seconds, exim 500, zmailer I can't tell. Am I > >reading the graphs wrong? > > Where are you seeing these numbers? Eval 1, the individual graphs mostly. I'm using the point where the SMTP fin count maxes as the terminal point, even though some DNS activity occurs after that with some mailers. But I don't see why I was confused about zmailer now (other than the trailing DNS activity), seems to finish at about 190. > >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.) > > Me too, because I just don't see that. Which graph(s) are you looking > at? http://www.kyoto.wide.ad.jp/mta/eval1/perf1-zmailer.gif (evaluation 1, zmailer). The SMTP syn count has peaked a bit under 200 seconds, the SMTP fin count shortly thereafter. The DNS query and response count are at about 1275 then. By 1400 seconds, the DNS query and response count are up to about 1550. -- 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
"David Dyer-Bennet" <[EMAIL PROTECTED]> wrote: >Dave Sill <[EMAIL PROTECTED]> writes on 2 August 2000 at 10:14:56 -0400 > > > > 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) I don't see where you got 20 seconds. Here's the results in tabular form--numbers are all APPROXIMATE since I'm reading them from the graphs (the individual results by implementation): 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 >Also note that in the cached case postfix appears to beat qmail at >delivering all the mail, at least on one graph. I don't see that. >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. Yeah, that suprised me, too. Exim wins the prize for DNS frugality, though. >(postfix took 30 seconds, exim 500, zmailer I can't tell. Am I >reading the graphs wrong? Where are you seeing these numbers? >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.) Me too, because I just don't see that. Which graph(s) are you looking at? -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 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
"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
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
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
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
Dave Sill wrote: > 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). Good. > > > 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 I dont know yet the hardware configuration of the machine, unfortunally The lists will be very big, let me explain better: we will make a newsletter system, with msgs being sent to every our customer, perhaps several messages per day. I dont think the messages will be big, just a few lines of text, but I need that the messages cames to its destination in a few amount of time, because they will be some kind of "last news". Im searching the mailing list manager to use, but Im thought in use ezmlm... Any sugestions? Thanks! -- _ Fernando Costa de Almeida ICQ - 72293951
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
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
> 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
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
At 10:24 AM 8/2/00 -0300, Fernando Almeida wrote: >Ive just read the postfix documentation, and I would like to know about >how secure it is. Its know that qmail is a very secure system qmail will not be a secure system anymore if you delete the rcpthosts file which makes it open relay. the same will happens to postfix, if you don't set your main.cf correctly. So it depends on the administrator to make whether a system is secure or not.
Re: Mailing list performance
On Wed, 2 Aug 2000, Fernando Almeida 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. > > Ive just read the postfix documentation, and I would like to know about > how secure it is. Its know that qmail is a very secure system Check the bugtraq archives at securityfocus.com Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
Re: Mailing list performance
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. Ive just read the postfix documentation, and I would like to know about how secure it is. Its know that qmail is a very secure system Thanks, -- _ Fernando Costa de Almeida ICQ - 72293951
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]
