Reduce DI Allocations

[benaadams]

For 2000 plantext requests DI allocates 16,009 objects:

Clocking in at 788,304 bytes:

Which would mean if you were performing 1M rps the GC would have to flush 8,004,500 objects and 394 Mbytes per second, 788 Mbytes per second for 2M rps and 2.76GBytes (56M objects) per second for 7M rps (~10GbE saturation)

[benaadams]

This change cuts the object allocations for 2400 plantext requests from 16,009 to 58:

The bytes allocated from 788,304 to 4,664, also it should not grow per request:

As shown by 4800 plaintext requests demonstrating the same allocation:

So the GC should have limited work to do related to DI.

[benaadams]

Question should _createServiceAccessor be reset each time?

[benaadams]

Question should _createServiceAccessor be reset each time?

No, has no state, is pointer to current object's function

[benaadams]

Updated images @rynowak are they displaying?

[benaadams]

See aspnet/HttpAbstractions#402 (comment) for details on server run improvements (61.5k rps -> 1.49M rps)

[benaadams]

Tests were actually done for 2000 plaintext responses, so results are worse than reported at top. @davidfowl wanted some more details so breakdown for bytes as follows:

...

[benaadams]

Updated top numbers for actual requests performed

[benaadams]

All change... will update the figures from both sides

[rynowak]

Closing this due to 49520a2a73251a9f718743df4a43d26514021767

Reopen if you find more actionable work here.

[benaadams]

49520a2a73251a9f718743df4a43d26514021767 is an inscrutable reason... I assume you mean bbb9acf101d4f9b3b818834c60572f67ec16ac63 😀