Skip to content

Profile and performance test Diagnostics middleware #42700

Open
@brunolins16

Description

@brunolins16

During the #42384 I noticed that the Diagnostics middleware, mainly StatusCodePages middleware, allocated much more than expected

application statuscodepages nostatuscodepages+content
Max Working Set (MB) 179 186 +3.74%
Max GC Heap Size (MB) 90 94 +4.21%
Size of committed memory by the GC (MB) 117 119 +1.28%
Max Number of Gen 0 GCs / sec 41.00 25.00 -39.02%
Max Number of Gen 1 GCs / sec 1.00 13.00 +1,200.00%
Max Number of Gen 2 GCs / sec 0.00 1.00 +∞%
Max Time in GC (%) 2.00 1.00 -50.00%
Max Gen 0 Size (B) 3,152,512 5,146,600 +63.25%
Max Gen 1 Size (B) 9,309,256 5,376,536 -42.25%
Max Gen 2 Size (B) 1,970,808 6,406,424 +225.07%
Max LOH Size (B) 411,320 411,320 0.00%
Max POH Size (B) 3,472,456 3,451,856 -0.59%
Total Allocated Bytes 96,805,446,920 57,737,869,840 -40.36%
Max GC Heap Fragmentation 30 41 +36.47%
load statuscodepages nostatuscodepages+content
Requests/sec 1,354,620 1,429,729 +5.54%
Requests 20,454,730 21,588,730 +5.54%

nostatuscodepages+content => endpoints.MapGet("sample", () => Results.Content(new string(' ', 500), statusCode: 415));

new string(' ', 500) is similar to what the StatusCodePages does.

Since this middleware, and other Diagnostics middleware, will become more relevant after the introducing of ProblemDetails Services, we should do some profiling and optimizing of these middleware, including scenarios that produce a ProblemDetails payload.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-middlewareIncludes: URL rewrite, redirect, response cache/compression, session, and other general middlewares

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions