[Users] auth_db subscriber caching

[Bogdan-Andrei Iancu]

Klaus Darilion wrote:

>> actually authentication (at least is a secure setup) is done more 
>> often the location - you have many calls that needs to be 
>> authenticated, but never hitting the usrloc.
>>
>> if you consider doing a cache for auth_db, the key question is what 
>
>
> no, I'm doing not :-)

it was just a way of saying :)

> Just some discussion with myself about (open)ser performance.
>
> Thus, in a single server setup (userloc, authentication ... on the 
> same server) tuning userloc is negligible compared to tuning DB 
> connections. It only matters in distributed setups with e.g. multiple 
> proxies which do authentication and a single registrar.

IMHO I would say it is perfectly correct.

regards,
bogdan

>
> regards
> klaus
>
>> exactly to cache from the subscriber table - the problem is with the 
>> additional information (dynamically configured) to be loaded along 
>> with the passwd....
>>
>> regards,
>> bogdan
>>
>> Klaus Darilion wrote:
>>
>>> Bogdan-Andrei Iancu wrote:
>>>
>>>> Hi Klaus,
>>>>
>>>> the answer is simple - no, there is no caching in auth_db :)
>>>
>>>
>>>
>>> A typical call internal call is:
>>>
>>> INVITE -->
>>>        <-- 407
>>> ACK    -->
>>> INVITE w. credentials -->
>>>                           1. openser checks credentials
>>>                           against subscriber table
>>>                           2. openser lookup("location")
>>>                           3. t_relay()
>>>
>>> Thus, we have the high performant in-memory cached lookup() and 
>>> always a slow database connection.
>>>
>>> Thus, also if the lookup is incredible fast, the authentication is 
>>> the bottleneck. Or do I miss something?
>>>
>>> regards
>>> klaus
>>>
>>>
>>>
>>>>
>>>> regards,
>>>> bogdan
>>>>
>>>> Klaus Darilion wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> A stupid question: Is the subscriber table also cached inside 
>>>>> openser (like location table)?
>>>>>
>>>>> regards
>>>>> klaus
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>