Hi Guys, We have: auth_cache_size = 2048 #Kb auth_cache_ttl = 900 #life of the cache 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? Is this a good idea and can it be disabled? Some more questions: 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? 2. If it is per-login, is the time reset after every hit? If someone is using webmail and hitting the cache every 5 minutes, will the cache keep the information? 3. How does the cache size relate to number of distinct logins? Roughly how many auth datasets cached per 1MB of cache? Thanks! Daniel tg3 dovecot # dovecot --version 1.0.rc27 p.s. please CC my email so I know when this has been replied to. I will respond to group!
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.> 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.> 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.> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070806/906ff333/attachment-0002.bin>
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 =)