Discussion: WebJobs SDK Extensions Throughput Performance Improvements & Opportunities

[NickCraver]

This is a draft PR for discussion and not meant to be merged, think "issue with some code". I figured this was the easiest way to talk about areas we can improve throughput performance in the least spammy way possible.

Proposals Summary

These diffs are not proposed PRs. They are pain points or opportunities identified in profiling and experimentation where I think we can improve performance. It's likely some are viable and some are not due to constraints I'm unaware of (so let's talk!). The hope is that some of these findings help in making us faster and spur new discussions on the remaining.

Goals

• Optimize what we have, with equivalent functionality - not remove any functionality.
• Don't break any use cases we have today
• Make any improvements as small single-thing PRs, not one big batch

A lot of these I file under "papercuts". Except 1 very recent regression in the 4.x branch (which @fabiocav and @brettsam are looking at already), there is no large single item affecting performance that I can see. However, there are many small items we can potentially improve that add up. I'm numbering these in lists below so that they're easy to refer to and talk about in discussions in a quick way.

It's worth breaking these down and testing each we consider viable, though each may be a small gain in itself. In aggregate I'm seeing 24-38% gains (depending on scenario) with our typical 2 and 4 core VMs for a hello world scenario. We need to test this in App Services yet (private stamp issues...) and the gains will be proportionately smaller when the function itself is more expensive. See #7908 for performance data.

These proposals are split across 3 repos and need discussion PRs for each (I'll update this as I create PRs)

• (#7908) https://github.com/Azure/azure-functions-host
• (#2794) https://github.com/Azure/azure-webjobs-sdk
• (This PR) https://github.com/Azure/azure-webjobs-sdk-extensions

Optimizations: WebJobs SDK Extensions

1. ToInvokeString() generates the same string every time, with a (assumption) minimal cardinality. We can ConcurrentDictionary away this allocation to prevent repetition and reduce GC per request.
   • Notes from @paulbatum and @mathewc: People could be using request parameters in the path - while most probably aren't that's an unbounded cardinality so this improvement would need to exclude any path that include parameters so that the assumption of limited cardinality is valid.

Diff Notes

• Building on the latest SDK consistently tried to stick some XML docs in my root directory. I'm assuming this is legacy and/or a separate issue, but using the newer <GenerateDocumentation>true</GenerateDocumentation> resolved it correctly - I can PR this as a non-performance fix.