Could anyone tell me how to setup socket maps for the access,
virtusertable and aliases databases?

I think I can get the programming for it to work but I don't know how
to set up the mc file to tell all my maps to be socket maps and then to
get each one to work with it.

Any would be appreciated.

Thanks

stevfletchcom@gmail.com wrote:
> Could anyone tell me how to setup socket maps for the access,
> virtusertable and aliases databases?
>
> I think I can get the programming for it to work but I don't know how
> to set up the mc file to tell all my maps to be socket maps and then to
> get each one to work with it.
>
> Any would be appreciated.
>
> Thanks

You should be able to include the socket map definition on a per
feature basis as per documented in cf/README

Or you can override it in LOCAL_CONFIG

stevfletchcom@gmail.com writes:

> Could anyone tell me how to setup socket maps for the access,
> virtusertable and aliases databases?
>
> I think I can get the programming for it to work but I don't know how
> to set up the mc file to tell all my maps to be socket maps and then to
> get each one to work with it.
>
> Any would be appreciated.

Test this:
#v+
FEATURE(`access_db',`local:_path_to_socket_map_soc ket')dnl
FEATURE(`virtusertable',`local:_path_to_socket_map _socket')dnl
#v-

--
[pl2en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl

stevfletchcom@gmail.com wrote:

> Could anyone tell me how to setup socket maps for the access,
> virtusertable and aliases databases?

You don't want to do that (especially for "access") unless your
mail server is fairly quiet.

On a busy server, Sendmail makes a huge number of access DB lookups
(tens per message, depending on what FEATUREs you're using) and a
SOCKETMAP can really slow that down.

Regards,

David.

Once upon a time, David F. Skoll <dfs@roaringpenguin.com> said:
>On a busy server, Sendmail makes a huge number of access DB lookups
>(tens per message, depending on what FEATUREs you're using) and a
>SOCKETMAP can really slow that down.

A well-written socketmap server could have the whole access.db (or
equivalent) in cache, which would eliminate file opens and locks that
sendmail would otherwise have to do. Without knowing what the socketmap
server looks like, you wouldn't be able to tell if it would be faster or
slower than DB file access.

Or is there some other inherent inefficiency in the socketmap protocol
or implementation?
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Chris Adams wrote:
> Once upon a time, David F. Skoll <dfs@roaringpenguin.com> said:
>> On a busy server, Sendmail makes a huge number of access DB lookups
>> (tens per message, depending on what FEATUREs you're using) and a
>> SOCKETMAP can really slow that down.
>
> A well-written socketmap server could have the whole access.db (or
> equivalent) in cache, which would eliminate file opens and locks that
> sendmail would otherwise have to do. Without knowing what the socketmap
> server looks like, you wouldn't be able to tell if it would be faster or
> slower than DB file access.
>
> Or is there some other inherent inefficiency in the socketmap protocol
> or implementation?

Socket map adds *at least* four system calls (8 content switches) per
every query to handle communication "overhead". Sendmail can issue
around 30 access db queries per one single message incoming SMTP
connection [ 120 *extra* system calls, 240 *extra* content switches ].

In case of access db some gains cold be achieved by limiting number of
access db queries sent by sendmail.cf over socket e.g. instead of
sending *four* octet boundary queries sending one "full IP" query with
socket map server doing "the translation" to octet boundary queries.
[ the same with domain queries ]

--
[pl2en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl

Chris Adams wrote:

> Once upon a time, David F. Skoll <dfs@roaringpenguin.com> said:
>>On a busy server, Sendmail makes a huge number of access DB lookups
>>(tens per message, depending on what FEATUREs you're using) and a
>>SOCKETMAP can really slow that down.

> A well-written socketmap server could have the whole access.db (or
> equivalent) in cache, which would eliminate file opens and locks that
> sendmail would otherwise have to do.

Sendmail doesn't lock access.db when it just reads it. And I think it
only opens it once per message (and holds it open.)

> Without knowing what the socketmap
> server looks like, you wouldn't be able to tell if it would be faster or
> slower than DB file access.

The SOCKETMAP protocol itself introduces a lot of overhead, including
(as Andrej mentioned) context-switching. But it's easy enough to test:
Just write a socketmap server that always returns a constant value no
matter what the lookup, and then run some timings.

Regards,

David.

"David F. Skoll" <dfs@roaringpenguin.com> writes:

> Chris Adams wrote:
>
>> Once upon a time, David F. Skoll <dfs@roaringpenguin.com> said:
>>>On a busy server, Sendmail makes a huge number of access DB lookups
>>>(tens per message, depending on what FEATUREs you're using) and a
>>>SOCKETMAP can really slow that down.
>
>> A well-written socketmap server could have the whole access.db (or
>> equivalent) in cache, which would eliminate file opens and locks that
>> sendmail would otherwise have to do.
>
> Sendmail doesn't lock access.db when it just reads it. And I think it
> only opens it once per message (and holds it open.)
>
>> Without knowing what the socketmap
>> server looks like, you wouldn't be able to tell if it would be faster or
>> slower than DB file access.
>
> The SOCKETMAP protocol itself introduces a lot of overhead, including
> (as Andrej mentioned) context-switching. But it's easy enough to test:
> Just write a socketmap server that always returns a constant value no
> matter what the lookup, and then run some timings.

David, you are (mostly) right if you talk about using access db lookups
scheme *currently* implemented in sendmail.cf as *the one and only scheme*.
It has been designed for querying "*any* map".

Socket map daemons can use "much smarter" implementation than "any map"
common denominator and allow significant reductions of number of access
db queries in sendmail.cf required to get the same *or better*
flexibility e.g. one query of all four octet boundary queries for
prefixed and "no prefix query". It would turn 8 queries into one query.
[it would require changes/redesign in sendmail.cf].

P.S.
I remember a few discussion in which I suggested a way to get one lookup
support for CIDR *for btree only*. I am unwilling to treat current
"any map" querying scheme as "unchangeble".

--
[pl2en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl