|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: RE: spec queue and sorting
From: Jose Aguayo (JAguayo
JFAX.COM)Date: Wed Jul 05 2000 - 19:32:36 CDT
- Next message: Bennett Todd: "Re: "Selective" Relaying (was: Re: Sendmail vs Postfix)"
- Previous message: Philippe Gramoulle: "MySQL: database stress and performance questions"
- Maybe in reply to: ago
hollo.idg.hu: "spec queue and sorting"
- Maybe reply: Jose Aguayo: "RE: spec queue and sorting"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Can anyone direct me to smtpstone utilities documentation? If none exists -
any suggestions for benchmarking?
Thanks,
Jose
-----Original Message-----
From: wietse
porcupine.org [mailto:wietse
porcupine.org]
Sent: Tuesday, July 04, 2000 4:36 PM
To: postfix-users
postfix.org
Subject: Re: spec queue and sorting
ago
hollo.idg.hu:
>
> Hi !
> > > the file and move it to a directory where his daemon waits and
examines
> > > the file (and decide what to do with it). Somebody did somethig
similar ?
> >
> > Don't do this. Instead, use an alias that delivers the message to
> > "|command", or use a Postfix pipe transport that does the equivalent.
>
> Use an alias ? What do you mean ? "luser_relay=sms | mycommand " ? Or what
> ? Please give me an example.
/etc/postfix/main.cf
recipient_delimiter = +
luser_relay = foobar+$local
/etc/aliases:
foobar: "|command $EXTENSION"
Which appends the original recipient to foobar, and which executes
the command with as argument the original recipient.
> > Why is delivery to command much faster than delivery to disk?
> > Because CPUs are much faster than disks. Not to mention that
> That's the problem. The daemon is too fast and takes the first 15-20 bytos
> from the whole mail only. That's why we need saving and individual files.
This has NOTHING to do with speed.
You see incomplete messages because you have not provided for
synchronization between the reading and writing processes.
WIth your architecture, you will see incomplete emails at any speed.
> > having a daemon constantly scanning the disk for new mail ruins
> > the performance of the machine.
> That's the only thing what the machine is serving.
You still have not done performance measurements with the
smtpstone utilities?
Measurements will show immediately how quickly your architecture
saturates. I estimate your system is pretty much dead by the time
you have to process 5-10 messages per second.
Give the performance tools a try. They are shipped with Postfix
source code. I use them frequently to see if the system still
performs and if it delivers all mail.
> > What happens wehn multiple messages arrive for the same user before
> > the daemon discovers that the user has new mail?
> I dunno. I will ask the programmer. But I suspect that part of the job
> would be his.
People who design multi-access systems without proper synchronization
should be shot.
Wietse
- Next message: Bennett Todd: "Re: "Selective" Relaying (was: Re: Sendmail vs Postfix)"
- Previous message: Philippe Gramoulle: "MySQL: database stress and performance questions"
- Maybe in reply to: ago
hollo.idg.hu: "spec queue and sorting"
- Maybe reply: Jose Aguayo: "RE: spec queue and sorting"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]