Loading ...
Sorry, an error occurred while loading the content.

Re: Connection caching/SMTP piggybacking and postfix?

Expand Messages
  • Thorsten Glaser
    ... I was assuming that, when you already have a connection to a receiving MX, you’d not open another one but reuse the existing one, so it would, of course,
    Message 1 of 14 , Feb 28, 2013
    • 0 Attachment
      On Thu, 28 Feb 2013, Wietse Venema wrote:

      > > That?s untrue because it certainly makes a difference whether you
      > > send mails in parallel or serial, especially when the receiving
      >
      > Connection caching has nothing to do with concurrency. Sheesh.

      I was assuming that, when you already have a connection to a
      receiving MX, you’d not open another one but reuse the existing
      one, so it would, of course, have something to do with that.

      If not… well, that’s the qmail model.

      > I welcome you to propose a design that is as scalable as the rest

      I am *not* interested in Postfix. I’m not even primarily
      working with Postfix. I came here because I was suffering,
      on the receiving side, from perceived Postfix misbehaviour.
      I’ve got a configuration item with which I can reduce the
      possibility of the behaviour becoming an issue, which has
      helped me. That was it.

      bye,
      //mirabilos
      --
      tarent solutions GmbH
      Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
      Tel: +49 228 54881-393 • Fax: +49 228 54881-314
      HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
      Geschäftsführer: Boris Esser, Sebastian Mancke
    • Wietse Venema
      ... Concurrency is the number of simultaneous connections. It has nothing to do with connection caching, which is using one connection for more than one
      Message 2 of 14 , Feb 28, 2013
      • 0 Attachment
        Thorsten Glaser:
        > On Thu, 28 Feb 2013, Wietse Venema wrote:
        >
        > > > That?s untrue because it certainly makes a difference whether you
        > > > send mails in parallel or serial, especially when the receiving
        > >
        > > Connection caching has nothing to do with concurrency. Sheesh.
        >
        > I was assuming that, when you already have a connection to a
        > receiving MX, you?d not open another one but reuse the existing

        Concurrency is the number of simultaneous connections.

        It has nothing to do with connection caching, which is using one
        connection for more than one transaction.

        Both are configurable with Postfix.

        Wietse
      • Viktor Dukhovni
        ... One can t immediately re-use an existing connection when some other process is currently using it! To do that, one would have to always wait for the other
        Message 3 of 14 , Feb 28, 2013
        • 0 Attachment
          On Thu, Feb 28, 2013 at 01:16:26PM +0100, Thorsten Glaser wrote:

          > > Connection caching has nothing to do with concurrency. Sheesh.
          >
          > I was assuming that, when you already have a connection to a
          > receiving MX, you'd not open another one but reuse the existing
          > one, so it would, of course, have something to do with that.
          >
          > If not? well, that's the qmail model.

          One can't immediately re-use an existing connection when some other
          process is currently using it! To do that, one would have to always
          wait for the other process to relinquish the connection, which forces
          concurrency <= 1. This has nothing to do with qmail, which uses a
          recipient limit of 1 which leads to more deliveries with multi-recipient
          messages than with Postfix or Sendmail.

          Postfix reuses *idle* existing connections, but creates new ones
          in *parallel* up to the concurrency limit to avoid severely limiting
          throughput to destinations with high capacity in the face of high
          single message delivery latency.

          Sendmail has no concurrency limits at all, since each process runs
          in isolation (no queue-manager), it just hiccups at random
          when the CPU load is high, which is not a meaningful signal that
          the MTA should pause deliveries or refuse new connections.

          You mentioned a Sendmail QueueLA or RefuseLA of 8, this is a meagerly
          limit on modern multi-cpu server hardware. ~10 years ago, I was
          tuning multi-CPU Sendmail servers of that era with a QueueLA of 64.

          > > I welcome you to propose a design that is as scalable as the rest
          >
          > I am *not* interested in Postfix. I'm not even primarily
          > working with Postfix.

          You're also not interested in any form of critical thinking before
          you spout non sequiturs, or even a modicum of humility which would
          suggest asking how to improve latency in your two MTA setup, nor do
          you care to do any research, rather you barge in here in response to
          an 11-year old post blaming Postfix for Sendmail design flaws.

          I smell a troll, please don't come back.

          --
          Viktor.
        Your message has been successfully submitted and would be delivered to recipients shortly.