Here is from a Test machine with very low mail traffic and the suggested config changes:
real 0m51.42s user 0m0.05s sys 0m0.04s And here is from Prod with a high volume of traffic and the original configuration: real 1m24.74s user 0m0.05s sys 0m0.06s Still trying to get the application folks to simulate the same volume of traffic in Test so we can definitively see if the changes made a difference. -----Original Message----- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Viktor Dukhovni Sent: Friday, February 10, 2017 2:43 PM To: Postfix users <postfix-users@postfix.org> Subject: Re: dict_ldap_lookup questions > On Feb 10, 2017, at 2:27 PM, Gomes, Rich <gomes-r...@aramark.com> wrote: > > The reason the query is setup like that is we have several internal > domains and a user may have an alias for one or all of them depending > on their employment history. You've failed to understand my response. The "proxyAddresses" attribute is multi-valued, and returns results of the form "smtp:<rfc822address>". Nothing in Postfix can uses such results, so you're better off returning a single-valued attribute such as "mail". > Since it is working as expected, I'd rather leave it as is, unless you > feel it may be a contributor to the issue I am seeing. The primary recommendation is to use "proxy:ldap:" rather than "ldap:". You've not yet explained what you're using LDAP for. Is this a relay_recipient_maps table? Some other table that ignores the RHS value? Have you tested lookup latency with: $ domain=example.com # Replace with actual domain $ i=0; while (( i < 1024 )); do echo "$i-probe@$domain" i=$(( i + 1 )) done | time postmap -q - ldap:/table/file.cf The idea is to establish a single connection and then test ~1000 queries for distinct addresses (for a domain that matches the domain= constraints in the table definition). The actual addresses need not exist in LDAP. Report your results. -- Viktor.
