| 1 | | [[PageOutline]] |
| 2 | | = Cache Management = |
| 3 | | |
| 4 | | Because network connections are expensive in time, compute cycles and network bandwidth, a strong caching paradigm (love using that word) was implemented to help lower the use of resources and lower the response time. |
| 5 | | |
| 6 | | == Configuration == |
| 7 | | - the timeout and size can be tweaked as needed to support a particular environment. The system will send out an INFO alert if it's purging too quickly. |
| 8 | | - the memory cache can be completely disabled by setting the size to 0. This should only be done if you are using a single process, as the database interface *should* be caching results. |
| 9 | | == Lookups == |
| 10 | | - Each search to the AD server is through a cached LDAP filehandle. The restart option has been enabled to allow it to persist. |
| 11 | | - When valid data is found .. the data is pickled, and the key hashed and stored in a new table in the database called ad_cache. |
| 12 | | - It's also stored in a class variable {{{_cache}}} which is a dictionary. |
| 13 | | |
| 14 | | == Retrieval == |
| 15 | | - the memory cache is checked first |
| 16 | | - then the database cache |
| 17 | | - lastly the AD server itself is searched |
| 18 | | - Any results are then pushed back on the cache(s) |
| 19 | | |
| 20 | | == Integration == |
| 21 | | - data is cached by 'class' where appropriate to speed up processing, |
| 22 | | - all ldap searches are cached using a key which is a hashed combination of ( base_dn, scope, filter ) |
| 23 | | |
| 24 | | |
| 25 | | |
| | 1 | [[redirect(wiki:DirectoryAuthPlugin/CacheManagement)]] |
