[Dovecot] cache questions

[Daniel Watts]

Timo Sirainen wrote:
> On Mon, 2007-08-06 at 15:37 +0100, Daniel Watts wrote:
>> Seems to work well (though haven't tried looking at stats). Only problem 
>> is that every so often, one of our new users tries to log in quickly 
>> before the account is marked (in a db) as 'active'. They use the right 
>> password but the sql query fails because the active flag is not yet set.
>>
>> This results in their trying to log in and failing for 15 minutes (900 
>> seconds) until the cache clears.
>>
>> Is this dovecot caching negative results?
> 
> Yes.

Thanks. I am creating an Config>Authentication>Caching page on the wiki 
for you.

> 
>> Is this a good idea and can it be disabled?
> 
> It can't be disabled. Perhaps there could be a separate
> auth_cache_negative_ttl setting. OK, implemented for v1.1:
> http://hg.dovecot.org/dovecot/rev/6c48466c23fa
> 
> It might apply to v1.0 also.

Now *that* is service.

> 
>> 1. Is the expire time on a per-login basis or for the entire cache? If 
>> someone logs in 14 minutes after the last expiry is their data cached 
>> for just 1 minute?
> 
> 1 minute.

Would it be hard to make this per-user? Obviously that should lead to 
much better performance on non-persistant setups such as heavy webmail 
sites.

I'm guessing that on each lookup it checks the cache timestamp for that 
account. If it is expired it then does the full lookup and resets that 
timestamp.

Every x minutes a reaper comes through and clears out stale cache 
entries (timestamp old than x minutes).

This way there is no 15 minute surge of authentications and users see a 
quick auth each time after they log in.

> 
>> 3. How does the cache size relate to number of distinct logins? Roughly 
>> how many auth datasets cached per 1MB of cache?
> 
> It depends on what kind of information you're returning. Dovecot caches
> both passdb and userdb lookups, so it's basically the length of the
> string that contains all the returned data.
> 
> For example if you set auth_debug=yes you'll see in logs:
> 
> client out: OK    1       user=tss
> master out: USER  458     tss    uid=1000        gid=1000        home=/home/tss
> 
> Password is hidden. These are stored in two different cache entries.
> Besides this information it also contains cache key which contains at
> least username and possibly other information. Also some internal
> records are counted.
> 
> So above two would use about 65 bytes for the strings and maybe 30 bytes
> for internal records.

Thanks for this. I probably return a bit more data (longer usernames and 
paths) - about 200 bytes. Which means my cache of 2MB can store 10,000 
entries - plenty for my ~100 simultaneous users load =)