On Wed, Feb 22, 2012 at 09:17:24AM +0100, Angel L. Mateo wrote:
> >Postfix is not monolithic, so cleanup(8) repeats some queries
> >made by smtpd(8), and in smtpd(8) some queries are repeated because
> >this makes the code more modular.
>
> I know it needs to repeat queries. But, in this case, why not
> implementing a cache for such maps?
Additional complexity is not free, someone has to write, test and
maintain the code. Code improvements are focused on useful outcomes.
Optimization of non-critical paths is not sufficiently useful IMHO.
> If I remember well in previous versions it did.
There has never been a working LDAP query cache in the OpenLDAP
library. Postfix support for the non-working query cache was
withdrawn soon after the discovery that the OpenLDAP query cache
was disfunctional and deprecated.
Don't confuse caching of address verification probe results, or postscreen
client test results, ... with caching of table lookup results. The former
in fact use uncached table lookups. The latter cache information about the
outside world (that is impossible or impractical to obtain with every
lookup) not the result of a table lookup.
Postfix has never had caching at the table-type driver level, and
probably never should, such caching would cause plenty of WTF when
table updates are not reflected in the behaviour of the MTA in a
timely manner.
People already complain from time to time about the tiny 1-element
cache in the transport lookup code that is re-discovered from time
to time in test environments when all mail is sent to a single
address...
There can be more caching in specific lookup contexts by various
Postfix services, e.g. smtpd(8) could cache a few more lookups
either for the lifetime of a client session, or LRU cache a small
number of key/value tuples for a particular type of lookup for the
server's lifetime. However, the cost-benefit analysis has to make
sense.
To reduce high query load, consider postscreen which typically
eliminates a decent fraction of botnet SMTP sessions without
performing any LDAP queries, ... just DNSBL lookups.
In practice, the query load is very rarely high enough to give a well
tuned LDAP or SQL server any trouble.
--
Viktor.
