You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Azure Function应用中ServicePointManager.DefaultConnectionLimit最佳设置位置

Setting 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 Startup class that implements IWebJobsStartup. 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.cs with a Main method, 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 Startup class that inherits from FunctionsStartup to 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 Run method—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

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.19 08:28:58