Kov?cs Albert:
> Hello Wietse,
>thanks for the clarification, I'd stick to a stable and supported
>method.
Thanks. And I with I had a better answer.
Speaking which, Postfix supports QMQP. This protocol is simpler
than SMTP, designed by Dan Bernstein, and is based on netstrings.
Netstrings are simple to implement and are already available as
libraries for pupular programming languages.
http://cr.yp.to/proto/qmqp.html
But this does nothing to remove the file system bottleneck.
>Can you give me a rough estimation on "moderate level" for such an
>environment where the only source of messages is the local injection?
>I mean messages per second or similar.
That depends totally on the file system, and the size of messages.
You can test this with the Postfix smtp-source utility. That is
part of the source code distribution (untar and "make") and normally
not installed.
As required by SMTP (and other) rules, Postfix must fsync() each
message before claiming that it has accepted the message.
On rust (i.e. rotating disks) this takes many milliseconds because
it involves updates of data blocks, inode blocks, bitmap blocks,
most or all of which are in different locations on the drive. Even
if you have a large write cache it will eventually fill up and heads
will have to move and wait for sectors to fly by.
On silicon (ramdisk, SSD) this takes less time because there are
no head movement or rotational latency.
>And is there a way to force the smtp utility to send multiple
>messages through an already established connection? Ie. instead
>of QUIT, continue with another MAIL FROM command (the recipient
>address is fixed and the same for all messages). Or the postfix
>smtp program is smart enough and does so whenever it's possible
>without instructing it?
As required by the SMTP protocol Postfix accepts multiple messages
over one SMTP connection. But that does nothing to remove the file
system bottleneck.
Wietse
