We have been scaling out our user base, and observed a performance issue impacting Authenticate. It appears that every user logon is adding a row to the AbpUserTokens table, and as this table grows the time taken for that user to Authenticate also increases. Once there are more than a few thousand rows, the delay can move into seconds (we have seen up to 15 secs before we located the issue). If we clear the user's rows in the table to a small count, then performance comes back. The users in question are internally defined API users, although we do have some external google users.
What is the intent of this table (none of the rows I saw have anything in Value column)? Is keeping history intended?
6 Answer(s)
-
0
see: https://github.com/aspnetzero/aspnet-zero-core/issues/1516 https://github.com/aspnetzero/aspnet-zero-core/issues/1497
-
0
As I see it now, if a token holder calls Logout, then related entries in this table are cleared, but the entries are left behind whenever connections are simply terminated.
Please correct me if I am wrong, but it should be safe to schedule a data maintenance task to remove any records referring to tokens which have clearly expired?
-
0
No problem, you can clean up expired tokens regularly.
https://github.com/aspnetzero/aspnet-zero-core/pull/1538#issuecomment-483530020
-
0
OK. i'll do that.
I think you are on the right track with your comment on 1538.
-
0
@aidancostcoau
https://github.com/aspnetboilerplate/aspnetboilerplate/pull/4441
-
0
If I set ExpireDate (in AbpUserTokens table) manually for specific user (this kind of user is used for external system authentication which does NOT call Login and Logout method - just using bearer token which is generated by us (first login) and then ExpireDate is "manually corrected" to (very) distant future datetime).
Is this approach "stable and good enough) for life-long authentication? (I know that from a security perspective this is obviously very bad to have jwt token with a distant expiration date.)
