scaling issues with security_tokens

I am having a problem with scaling squirrelmail because of the update
frequency of the security_tokens. It seems as though a new
security_token is generated and put into the database (via a REPLACE
INTO userprefs) everytime a squirrelmail user does anything in
squirrelmail... perhaps with some exceptions (I did not look that
closely).

This may not be a big deal when you only have a few users, but when you
have 39k users, this starts to really hammer the database. It also makes
replication a major pain because every single one of those userprefs
updates results in a query written to the binary log that then needs to
be replayed on the replication slave.

I've set $max_token_age_days = 1; but that only affects how much data
accumulates in the security_tokens, but it doesn't affect the number of
updates. 

Besides turning these off, which does not seem like a good idea, could
there be a better way to handle these?

thanks!
micah


--

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: [email protected]
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCgAGBQJPHyD+AAoJEIy/mjIoYaeQcCYP/RoNOp2V9Jzc/RJ/XOR2WBeN
e5pM50H0nGHS5zE2waxmmPHWQ75UZePHsHyH1pUrj/YTT6Ayy6Y2TBcCoVd6OxIu
OZ7OXPcAzs7FOJG85IIGflnq9PkDYGe99qKAhoxBtRBw8JHkZLbeAkf7H+ZDvfBw
1zGmmdqprGDyvff8wHza8UjNlHJytLWmFqTNvD6AjexTgQ+utBRDOQx193Pyw/IS
hUIL1SxSl7eG1tV0zF7J5t844ad73wsOtQL16psn+440jNsUQhVqbiBAcXVvU59F
tLLzphpWsEzkRZIa5ST6q3e41HSQyNWVJhMQM6JZXPTPtBMcYL+MhGGsA2cYwPBm
59bOPoVKtTmHCMeWsvx4Lh3BcYpNhWIoOOtWalD+0M9PAyT6h1v/a3wllYcYRctL
XE1ibTWa+nuNvKGMzhvCJAbhhumOsP0VccAPP742DvXLNIIDc6iyq/Vvtg7v4+ND
IYJviVkWbZSZ744Q/ZzVvi1EnO4jYn+4aiu5tD7+rjMsPjGRKVX8G9QFMFibMofq
eZz0NyoDjfwjJhIVRu0HzWYWkXzZ5ft+3cJXVZtLhz22lRnq9d8VaFKQGEKIF6sg
u2EzpC5Wl+Fy+fxEx0RkI1cRaHpMGdcXxFRNInNziKKOkSRjxY4i70KJlQ+M621T
vjfXK7rpVct2/pTBKK1m
=7gIT
-----END PGP SIGNATURE-----