Azure Function应用中ServicePointManager.DefaultConnectionLimit最佳设置位置
ServicePointManager.DefaultConnectionLimit in Azure Functions Great question! Let’s break down how to handle this, especially since Azure Functions don’t have a traditional Main method like WebJobs, and you’re working with the Consumption Plan.
First, Why This Matters
Quick context: ServicePointManager.DefaultConnectionLimit controls the maximum number of concurrent connections your app can open to a single server. The default value is pretty low (2 for .NET Framework, higher but still sometimes restrictive for .NET Core/.NET 5+), so tweaking it can boost throughput if your function makes multiple outbound calls.
Best Locations to Set the Value
Since Functions use different initialization pathways than WebJobs, here are the most reliable spots based on your runtime:
1. .NET Framework Functions (Script or Class Library)
- Static Constructor in Your Function Class: Static constructors run once per app domain, which aligns with when a function instance starts up. This works perfectly even in the Consumption Plan, where instances spin up/down dynamically—each new instance will run this once.
Example code:public static class MyHttpTriggerFunction { // Runs once when the instance initializes static MyHttpTriggerFunction() { ServicePointManager.DefaultConnectionLimit = 100; // Adjust to your needs } [FunctionName("MyHttpTriggerFunction")] public static async Task<IActionResult> Run( [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req, ILogger log) { // Your function logic here } } - Alternative: Startup Class (Functions v2+): If you prefer a centralized setup, create a
Startupclass that implementsIWebJobsStartup. This runs once when the entire function app starts.
Example:using Microsoft.Azure.WebJobs; using Microsoft.Azure.WebJobs.Hosting; using System.Net; [assembly: WebJobsStartup(typeof(MyFunctionApp.Startup))] namespace MyFunctionApp { public class Startup : IWebJobsStartup { public void Configure(IWebJobsBuilder builder) { ServicePointManager.DefaultConnectionLimit = 100; } } }
2. .NET Core/.NET 5+ Functions
- Isolated Worker Model: This model actually has a
Program.cswith aMainmethod, so you can set the value directly there during host configuration:var host = new HostBuilder() .ConfigureFunctionsWorkerDefaults() .ConfigureServices(services => { ServicePointManager.DefaultConnectionLimit = 100; }) .Build(); host.Run(); - In-Process Model: Use a
Startupclass that inherits fromFunctionsStartupto set the value during app initialization:using Microsoft.Azure.Functions.Extensions.DependencyInjection; using Microsoft.Extensions.DependencyInjection; using System.Net; [assembly: FunctionsStartup(typeof(MyFunctionApp.Startup))] namespace MyFunctionApp { public class Startup : FunctionsStartup { public override void Configure(IFunctionsHostBuilder builder) { ServicePointManager.DefaultConnectionLimit = 100; } } }
Critical Notes for the Consumption Plan
- Each scaled-out instance will run the initialization code (static constructor or Startup class) exactly once when it spins up. Your setting applies per instance, which is exactly what you want for consistent connection limits across all running instances.
- Never set this inside your function's
Runmethod—that would execute every time the function runs, which is redundant and could cause unexpected behavior if the value gets reset multiple times.
About That v1.0.9 Tools Warning
The warning suggesting you set this in a WebJob’s Main method is just a holdover from WebJob patterns. Azure Functions have their own initialization flow, so the options above are the correct replacements. You can safely ignore that warning once you’ve implemented the setting in one of the recommended spots.
内容的提问来源于stack exchange,提问作者Michael Daw

