Update performance-testing.md

msal-dotnet-articles/advanced/performance-testing.md

@@ -6,7 +6,7 @@ title: Performance testing of MSAL.NET
 
 [Microsoft.Identity.Test.Performance](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/tree/main/tests/Microsoft.Identity.Test.Performance) project uses [BenchmarkDotNet](https://benchmarkdotnet.org/articles/overview.html) library for performance testing of MSAL functionality. [Program.cs](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/main/tests/Microsoft.Identity.Test.Performance/Program.cs) contains benchmark classes used to test different scenarios.
 
-This performance test project is a console app. Behind the scenes when the project is run, BenchmarkDotNet builds and outputs this test project into a temporary working directory. Then it creates a separate process where all the benchmarking measurements are done. 
+This performance test project is a console app. Behind the scenes when the project is run, BenchmarkDotNet builds and outputs this test project into a temporary working directory. Then it creates a separate process where all the benchmarking measurements are done.
 
 BenchmarkDotNet is customizable.  BenchmarkDotNet tests are set up similarly to unit tests, using attributes. Benchmarks can be parametrized. There are global and iteration [setup and cleanup](https://benchmarkdotnet.org/articles/features/setup-and-cleanup.html) methods that can be used to setup the environment before running actual tests. The number of times that a benchmark should run can be customized, although it is recommended to use the defaults, as the BenchmarkDotNet does it's own pre-processing to find the optimal number of runs. [How it works](https://benchmarkdotnet.org/articles/guides/how-it-works.html) guide describes the steps that BenchmarkDotNet takes to run the benchmarks. BenchmarkDotNet supports running tests on [multiple frameworks](https://benchmarkdotnet.org/articles/configs/toolchains.html#multiple-frameworks-support).
 
@@ -73,7 +73,7 @@ The tests cover common MSAL usage scenarios.
   - A simple scenario few cache entries with few tokens in each (ex. few resources accessed for each tenant or by one user).
   - The more common scenario is many cache entries with few tokens in each. This also shows that the number of cache entries / keys doesn't affect the performance much (besides internal .NET operations) because the filtering operations to find a token are done only on the specific cache entry, which is retrieved in O(n) time.
   - A less common scenario is a lot of tokens per cache entry (generally for client credential app tokens).
-- **Enabled token cache serialization** - whether cache serialization is enabled or disabled (as described in [docs](https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-net-token-cache-serialization?tabs=aspnetcore#monitor-cache-hit-ratios-and-cache-performance)). When disabled MSAL uses internal in-memory cache, pre-populated with tokens as described above. When enabled, MSAL pre-populates and serializes into a .NET Memory Cache structure. The serialization is what adds the perf hit between these two options.
+- **Enabled token cache serialization** - whether cache serialization is enabled or disabled (as described in [docs](/azure/active-directory/develop/msal-net-token-cache-serialization?tabs=aspnetcore#monitor-cache-hit-ratios-and-cache-performance)). When disabled MSAL uses internal in-memory cache, pre-populated with tokens as described above. When enabled, MSAL pre-populates and serializes into a .NET Memory Cache structure. The serialization is what adds the perf hit between these two options.
 
 ## Improvements and test results