Token Cache serialization performance - AzureAD/microsoft-authentication-extensions-for-java GitHub Wiki
-
Application model of MSAL SDK implies that the whole token cache persisted as JSON document. If cache persistence is configured, MSAL uses persistent state as "single source of truth", which means that persistent state is read for every cache access.
-
Generally speaking persisted cache is read and deserialized every time when MSAL API called. Serialization/de-serialization is relatively expensive operation. Time taken on serialization / de-serialization of Token Cache was measured (JVM, Jackson library, Mac book pro 16 GB):
| Num of accounts | Num of tokens | Time taken in ms |
|---|---|---|
| 1 | 1 | 110 |
| 1 | 10 | 110 |
| 1 | 100 | 130 |
| 1 | 1000 | 170 |
| 1 | 10000 | 600 |
| 5 | 1 | 120 |
| 5 | 10 | 120 |
| 5 | 100 | 150 |
| 5 | 1000 | 450 |
| 5 | 10000 | 2000 |
-
Number or accounts in the cache for public client application typically one, but might be few. Cost of cache Serialization/de-serialization is almost same up to 1K tokens. The size of token cache for public client applications should not exceed few dozens, so cache access performance should not degrade along the time of app usage.
-
However we might consider an option to add to MSAL the logic of removing expired access tokens, to keep size of the cache as small as possible.