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

Re: Connection caching/SMTP piggybacking and postfix?

Expand Messages
  • Wietse Venema
    Thorsten Glaser: [ Charset UTF-8 unsupported, converting... ] ... Connection caching has nothing to do with concurrency. Sheesh. Wietse
    Message 1 of 14 , Feb 28, 2013
    • 0 Attachment
      Thorsten Glaser:
      [ Charset UTF-8 unsupported, converting... ]
      > On Wed, 27 Feb 2013, Viktor Dukhovni wrote:
      >
      > > No, connection caching has nothing to do with concurrency. Whether
      > > connections are cached, or not, Postfix will attempt parallel
      > > delivery up to the configured concurrency limit:
      >
      > Hrm. Okay, lowering default_destination_concurrency_limit is certainly
      > a viable workaround. I?m not the Postfix expert here, and he didn?t
      > suggest it to me.
      >
      > > of the MX hosts for a destination is unreachable. The load on the
      > > remote server is identical with and without connection caching.
      >
      > 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.

      Wietse
    • 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 2 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 3 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 4 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.