|
| 1 | +--- |
| 2 | +title: How to manage connections in Azure Functions |
| 3 | +description: Learn how to avoid performance problems in Azure Functions by using static connection clients. |
| 4 | +services: functions |
| 5 | +documentationcenter: |
| 6 | +author: tdykstra |
| 7 | +manager: cfowler |
| 8 | +editor: '' |
| 9 | + |
| 10 | +ms.service: functions |
| 11 | +ms.workload: na |
| 12 | +ms.devlang: na |
| 13 | +ms.topic: article |
| 14 | +ms.date: 05/18/2018 |
| 15 | +ms.author: tdykstra |
| 16 | +--- |
| 17 | + |
| 18 | +# How to manage connections in Azure Functions |
| 19 | + |
| 20 | +Functions in a function app share resources, and among those shared resources are connections — HTTP connections, database connections, and connections to Azure services such as Storage. When many functions are running concurrently it's possible to run out of available connections. This article explains how to code your functions to avoid using more connections than they actually need. |
| 21 | + |
| 22 | +## Connections limit |
| 23 | + |
| 24 | +The number of available connections is limited partly because a function app runs in the [Azure App Service sandbox](https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox). One of the restrictions that the sandbox imposes on your code is a [cap on the number of connections, currently 300](https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#numerical-sandbox-limits). When you reach this limit, the functions runtime creates a log with the following message: `Host thresholds exceeded: Connections`. |
| 25 | + |
| 26 | +Chances of exceeding the limit increase when the [scale controller adds function app instances](functions-scale.md#how-the-consumption-plan-works). Each function app instance can be invoking functions many times at once, and all of these functions are using connections that count toward the 300 limit. |
| 27 | + |
| 28 | +## Use static clients |
| 29 | + |
| 30 | +To avoid holding more connections than necessary, reuse client instances rather than creating new ones with each function invocation. .NET clients like the `HttpClient`, `DocumentClient`, and Azure Storage clients can manage connections if you use a single, static client. |
| 31 | + |
| 32 | +Here are some guidelines to follow when using a service-specific client in an Azure Functions application: |
| 33 | + |
| 34 | +- **DO NOT** create a new client with every function invocation. |
| 35 | +- **DO** create a single, static client that can be used by every function invocation. |
| 36 | +- **CONSIDER** creating a single, static client in a shared helper class if different functions use the same service. |
| 37 | + |
| 38 | +## HttpClient code example |
| 39 | + |
| 40 | +Here's an example of function code that creates a static `HttpClient`: |
| 41 | + |
| 42 | +```cs |
| 43 | +// Create a single, static HttpClient |
| 44 | +private static HttpClient httpClient = new HttpClient(); |
| 45 | + |
| 46 | +public static async Task Run(string input) |
| 47 | +{ |
| 48 | + var response = await httpClient.GetAsync("http://example.com"); |
| 49 | + // Rest of function |
| 50 | +} |
| 51 | +``` |
| 52 | + |
| 53 | +A common question about the .NET `HttpClient` is "Should I be disposing my client?" In general, you dispose objects that implement `IDisposable` when you're done using them. But you don't dispose a static client because you aren't done using it when the function ends. You want the static client to live for the duration of your application. |
| 54 | + |
| 55 | +## DocumentClient code example |
| 56 | + |
| 57 | +`DocumentClient` connects to a Cosmos DB instance. The Cosmos DB documentation recommends that you [use a singleton Azure Cosmos DB client for the lifetime of your application](https://docs.microsoft.com/en-us/azure/cosmos-db/performance-tips#sdk-usage). The following example shows one pattern for doing that in a function. |
| 58 | + |
| 59 | +```cs |
| 60 | +#r "Microsoft.Azure.Documents.Client" |
| 61 | +using Microsoft.Azure.Documents.Client; |
| 62 | + |
| 63 | +private static Lazy<DocumentClient> lazyClient = new Lazy<DocumentClient>(InitializeDocumentClient); |
| 64 | +private static DocumentClient documentClient => lazyClient.Value; |
| 65 | + |
| 66 | +private static DocumentClient InitializeDocumentClient() |
| 67 | +{ |
| 68 | + // Perform any initialization here |
| 69 | + var uri = new Uri("example"); |
| 70 | + var authKey = "authKey"; |
| 71 | + |
| 72 | + return new DocumentClient(uri, authKey); |
| 73 | +} |
| 74 | + |
| 75 | +public static async Task Run(string input) |
| 76 | +{ |
| 77 | + Uri collectionUri = UriFactory.CreateDocumentCollectionUri("database", "collection"); |
| 78 | + object document = new { Data = "example" }; |
| 79 | + await documentClient.UpsertDocumentAsync(collectionUri, document); |
| 80 | + |
| 81 | + // Rest of function |
| 82 | +} |
| 83 | +``` |
| 84 | + |
| 85 | +## Next steps |
| 86 | + |
| 87 | +For more information about why static clients are recommended, see [Improper instantiation antipattern](https://docs.microsoft.com/azure/architecture/antipatterns/improper-instantiation/). |
| 88 | + |
| 89 | +For more Azure Functions performance tips, see [Optimize the performance and reliability of Azure Functions](functions-best-practices.md). |
0 commit comments