Confirmed users, Bureaucrats and Sysops emeriti
812
edits
User:Mconnor/Pending/CookieEviction: Difference between revisions
Jump to navigation
Jump to search
User:Mconnor/Pending/CookieEviction (view source)
Revision as of 10:47, 2 September 2008
, 2 September 2008→Plan
m (→Plan) |
(→Plan) |
||
| Line 15: | Line 15: | ||
In order to leave behaviour intact for existing consumers, I propose to add a new value to network.cookie.lifetimePolicy for this new behaviour. I will add a new pref (network.cookie.minimumEvictionTime) to control the minimum number of days cookies should be retained for. When we are doing cookie evictions we will only expire cookies that are older than that number of days. | In order to leave behaviour intact for existing consumers, I propose to add a new value to network.cookie.lifetimePolicy for this new behaviour. I will add a new pref (network.cookie.minimumEvictionTime) to control the minimum number of days cookies should be retained for. When we are doing cookie evictions we will only expire cookies that are older than that number of days. | ||
== Cookie Eviction == | |||
On startup, do a COUNT where lastAccessed > minAge | |||
* If count is greater than the soft cap: | |||
** Only query in cookies where lastAccessed >= minAge and expiry is in the future | |||
** (async, on a delay) delete all cookies where lastAccessed < minAge or expiry < now | |||
* If count is less than the soft cap, its a little trickier! | |||
** First, switch writes to async, and remove the batching hack which makes lastAccessed not unique. | |||
** Do a selective query ordered, descending, by lastAccessed, with the soft cap as the limit. SQLite query time is not the bulk of the time we spend reading in cookies, and any added query overhead should be countered by reading in fewer cookies. | |||
** On reading the last cookie, record the lastAccessed time (oldestCookie). | |||
** (async on a delay) delete all cookies where lastAccessed < oldestCookie or expiry < now | |||
We will _not_ do evictions during a session, in the general case, to minimize sqlite overhead (even with async, deletes are not free, and could be 5-10 ms during pageload for the "add a cookie, delete a cookie" eviction method we currently use). However, we will have a "panic number" to avoid a very long-running session from storing a truly massive number of cookies. This number will be somewhere between 5x and 10x the soft cap. We don't expect to hit this often, but the best solution seems to be to repeat the init process and repeat the startup filtering/delayed cleanup behaviour. | |||