none
HttpClient best practices? RRS feed

  • Question

  • According to the MSDN documentation (https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=netframework-4.7.1) it says:

    "HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors"

    Something similar is mentioned here: https://docs.microsoft.com/en-us/azure/architecture/antipatterns/improper-instantiation/ which was linked from an Azure Functions best practices page.

    What does this mean in the context of Azure Functions? Lets say I have 10 functions in my function app, all which need to use an HttpClient. Should I somehow share 1 client across all the functions? I'm not sure of the best way to do that other than statically declaring it, but I'm not 100% clear on how static variables work with functions. I believe I read that static vars are shared across all functions within a function app, but what happens if your app scales to X instances?

    Edit: by instances I mean the "instance count" that can be set under "scale out" in your app's plan.
    • Edited by Architekt909 Friday, March 2, 2018 9:15 PM Clarifying "instances"
    Friday, March 2, 2018 8:03 PM

Answers

  • each "instance" will be running on a completely separate VM. So the sharing of static variables are across all your functions in a function app within an instance.

    You don't need to overthink it really. Just declaring a static object or a singleton pattern that all your functions access HttpClient through is all you need. That would prevent the socked exhaustion issue and if you scale to 100 instances, they will be running in a 100 different isolated VMs, so you don't have to worry about sharing that across these instances.


    Software Engineer - Azure Functions

    • Marked as answer by Architekt909 Friday, March 2, 2018 10:06 PM
    Friday, March 2, 2018 10:04 PM

All replies

  • There will always be one and only one static variable for a class. Period. I am not sure what would happen if a program never creates an instance of a class but that is not relevant here. You can assume that the runtime will automatically create the single static variable when the program begins and the number of instances of the class do not make a difference. See Fields (C# Programming Guide) for more.


    Sam Hobbs
    SimpleSamples.Info

    Friday, March 2, 2018 9:10 PM
  • Sorry I was unclear when I meant "instances". I wasn't referring to the number of times a class has been instantiated. I was replying to the number of instances I have my function app set to scale to, which can be up to 10 on the Azure portal (at least with my current plan)

    Friday, March 2, 2018 9:13 PM
  • each "instance" will be running on a completely separate VM. So the sharing of static variables are across all your functions in a function app within an instance.

    You don't need to overthink it really. Just declaring a static object or a singleton pattern that all your functions access HttpClient through is all you need. That would prevent the socked exhaustion issue and if you scale to 100 instances, they will be running in a 100 different isolated VMs, so you don't have to worry about sharing that across these instances.


    Software Engineer - Azure Functions

    • Marked as answer by Architekt909 Friday, March 2, 2018 10:06 PM
    Friday, March 2, 2018 10:04 PM