Målbaserad skalning
Målbaserad skalning ger kunderna en snabb och intuitiv skalningsmodell och stöds för närvarande för dessa bindningstillägg:
Målbaserad skalning ersätter den tidigare inkrementella skalningsmodellen i Azure Functions som standard för dessa tilläggstyper. Inkrementell skalning har lagts till eller tagits bort som högst en arbetare vid varje ny instansfrekvens, med komplexa beslut om när du ska skala. Däremot tillåter målbaserad skalning uppskalning av fyra instanser i taget, och skalningsbeslutet baseras på en enkel målbaserad ekvation:
I den här ekvationen refererar händelsekällans längd till antalet händelser som måste bearbetas. Standardvärdena för målkörningar per instans kommer från de SDK:er som används av Azure Functions-tilläggen. Du behöver inte göra några ändringar för att målbaserad skalning ska fungera.
Att tänka på
Följande överväganden gäller när du använder målbaserad skalning:
- Målbaserad skalning är aktiverad som standard för funktionsappar i förbrukningsplanen, Flex Consumption-planen och Elastic Premium-abonnemangen. Händelsedriven skalning stöds inte när du kör dedikerade planer (App Service).
- Målbaserad skalning är aktiverad som standard från och med version 4.19.0 av Functions-körningen.
- När du använder målbaserad skalning respekteras fortfarande skalningsgränser. Mer information finns i Begränsa utskalning.
- För att uppnå den mest exakta skalningen baserat på mått använder du bara en målbaserad utlöst funktion per funktionsapp. Du bör också överväga att köra i en Flex Consumption-plan som erbjuder skalning per funktion.
- När flera funktioner i samma funktionsapp begär att skalas ut samtidigt används en summa för dessa funktioner för att fastställa ändringen i önskade instanser. Funktioner som begär att skala ut åsidosättningsfunktioner som begär att skalas in.
- När det finns inskalningsbegäranden utan utskalningsbegäranden används den maximala skalningen i värdet.
Avregistrera dig
Målbaserad skalning är aktiverad som standard för funktionsappar som finns i en förbrukningsplan eller i ett Premium-abonnemang. Om du vill inaktivera målbaserad skalning och återgå till inkrementell skalning lägger du till följande appinställning i funktionsappen:
| Programinställning | Värde |
|---|---|
TARGET_BASED_SCALING_ENABLED |
0 |
Anpassa målbaserad skalning
Du kan göra skalningsbeteendet mer eller mindre aggressivt baserat på appens arbetsbelastning genom att justera målkörningar per instans. Varje tillägg har olika inställningar som du kan använda för att ange målkörningar per instans.
Den här tabellen sammanfattar de host.json värden som används för målkörningarna per instansvärden och standardvärdena:
| Anknytning | host.json värden | Standardvärde |
|---|---|---|
| Event Hubs (tillägg v5.x+) | extensions.eventHubs.maxEventBatchSize | 100* |
| Event Hubs (tillägg v3.x+) | extensions.eventHubs.eventProcessorOptions.maxBatchSize | 10 |
| Event Hubs (om det definieras) | extensions.eventHubs.targetUnprocessedEventThreshold | saknas |
| Service Bus (Extension v5.x+, Single Dispatch) | extensions.serviceBus.maxConcurrentCalls | 16 |
| Service Bus (Extension v5.x+, Single Dispatch Sessions Based) | extensions.serviceBus.maxConcurrentSessions | 8 |
| Service Bus (tillägg v5.x+, batchbearbetning) | extensions.serviceBus.maxMessageBatchSize | 1000 |
| Service Bus (Functions v2.x+, Single Dispatch) | extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls | 16 |
| Service Bus (Functions v2.x+, Single Dispatch Sessions Based) | extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions | 2000 |
| Service Bus (Functions v2.x+, Batch Processing) | extensions.serviceBus.batchOptions.maxMessageCount | 1000 |
| Lagringskö | extensions.queues.batchSize | 16 |
* Standardvärdet maxEventBatchSize ändrades i v6.0.0 i Microsoft.Azure.WebJobs.Extensions.EventHubs paketet. I tidigare versioner var det här värdet 10.
För vissa bindningstillägg anges målkörningar per instans med hjälp av ett funktionsattribut:
| Anknytning | Inställning för funktionsutlösare | Standardvärde |
|---|---|---|
| Apache Kafka | lagThreshold |
1000 |
| Azure Cosmos DB | maxItemsPerInvocation |
100 |
Mer information finns i exempelkonfigurationerna för tillägg som stöds.
Premium-plan med körningsskalningsövervakning aktiverat
När körningsskalningsövervakning är aktiverat hanterar själva tilläggen dynamisk skalning. Det beror på att skalningskontrollanten inte har åtkomst till tjänster som skyddas av ett virtuellt nätverk. När du har aktiverat körningsskalningsövervakning måste du uppgradera tilläggspaketen till de här lägsta versionerna för att låsa upp de extra målbaserade skalningsfunktionerna:
| Tilläggets namn | Lägsta version som krävs |
|---|---|
| Apache Kafka | 3.9.0 |
| Azure Cosmos DB | 4.1.0 |
| Event Hubs | 5.2.0 |
| Service Bus | 5.9.0 |
| Lagringskö | 5.1.0 |
Stöd för dynamisk samtidighet
Målbaserad skalning ger snabbare skalning och använder standardvärden för målkörningar per instans. När du använder Service Bus, Lagringsköer eller Kafka kan du också aktivera dynamisk samtidighet. I den här konfigurationen bestäms målkörningarna per instansvärde automatiskt av funktionen för dynamisk samtidighet. Den börjar med begränsad samtidighet och identifierar den bästa inställningen över tid.
Tillägg som stöds
Hur du konfigurerar målbaserad skalning i din host.json-fil beror på den specifika tilläggstypen. Det här avsnittet innehåller konfigurationsinformation för de tillägg som för närvarande stöder målbaserad skalning.
Service Bus-köer och -ämnen
Service Bus-tillägget stöder tre körningsmodeller som bestäms av attributen IsBatched och IsSessionsEnabled för Din Service Bus-utlösare. Standardvärdet för IsBatched och IsSessionsEnabled är false.
| Körningsmodell | IsBatched | IsSessionsEnabled | Inställning som används för målkörningar per instans |
|---|---|---|---|
| Bearbetning av enskild sändning | falskt | falskt | maxConcurrentCalls |
| Bearbetning av enskild sändning (sessionsbaserad) | falskt | true | maxConcurrentSessions |
| Batchbearbetning | true | falskt | maxMessageBatchSize eller maxMessageCount |
Kommentar
Skalningseffektivitet: För Service Bus-tillägget använder du Hantera behörigheter för resurser för den mest effektiva skalningen. Med lyssningsrättigheter återgår skalning till inkrementell skala eftersom kön eller ämneslängden inte kan användas för att informera skalningsbeslut. Mer information om hur du anger rättigheter i Service Bus-åtkomstprinciper finns i Auktoriseringsprincip för delad åtkomst.
Bearbetning av enskild sändning
I den här modellen bearbetar varje anrop av funktionen ett enda meddelande. Inställningen maxConcurrentCalls styr målkörningar per instans. Den specifika inställningen beror på versionen av Service Bus-tillägget.
Ändra inställningen host.json maxConcurrentCalls, som i följande exempel:
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxConcurrentCalls": 16
}
}
}
Bearbetning av enskild sändning (sessionsbaserad)
I den här modellen bearbetar varje anrop av funktionen ett enda meddelande. Beroende på antalet aktiva sessioner för ditt Service Bus-ämne eller din kö hyr varje instans dock en eller flera sessioner. Den specifika inställningen beror på versionen av Service Bus-tillägget.
Ändra inställningen host.json maxConcurrentSessions för att ange målkörningar per instans, som i följande exempel:
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxConcurrentSessions": 8
}
}
}
Batchbearbetning
I den här modellen bearbetar varje anrop av funktionen en uppsättning meddelanden. Den specifika inställningen beror på versionen av Service Bus-tillägget.
Ändra inställningen host.json maxMessageBatchSize för att ange målkörningar per instans, som i följande exempel:
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxMessageBatchSize": 1000
}
}
}
Event Hubs
För Azure Event Hubs skalar Azure Functions baserat på antalet obearbetade händelser som distribueras över alla partitioner i händelsehubben. Som standard är maxEventBatchSize attributen host.json som används för målkörningar per instans och maxBatchSize. Men om du väljer att finjustera målbaserad skalning kan du definiera en separat parameter targetUnprocessedEventThreshold som åsidosätter för att ange målkörningar per instans utan att ändra batchinställningarna. Om targetUnprocessedEventThreshold anges divideras det totala antalet obearbetade händelser med det här värdet för att fastställa antalet instanser, som sedan avrundas upp till ett antal arbetsinstanser som skapar en balanserad partitionsdistribution.
Kommentar
Eftersom Event Hubs är en partitionerad arbetsbelastning begränsas antalet målinstanser för Event Hubs av antalet partitioner i händelsehubben.
Den specifika inställningen beror på versionen av Event Hubs-tillägget.
Ändra inställningen host.json maxEventBatchSize för att ange målkörningar per instans, som i följande exempel:
{
"version": "2.0",
"extensions": {
"eventHubs": {
"maxEventBatchSize" : 100
}
}
}
När det definieras i targetUnprocessedEventThreshold host.jsonanvänds som målkörningar per instans i stället för maxEventBatchSize, som i följande exempel:
{
"version": "2.0",
"extensions": {
"eventHubs": {
"targetUnprocessedEventThreshold": 153
}
}
}
Lagringsköer
För v2.x+ för Lagringstillägget ändrar du host.json inställningen batchSize för att ange målkörningar per instans:
{
"version": "2.0",
"extensions": {
"queues": {
"batchSize": 16
}
}
}
Kommentar
Skalningseffektivitet: För lagringskötillägget räknas meddelanden med synlighetTimeout fortfarande i händelsekällans längd av API:erna för lagringskö. Detta kan orsaka överskalning av funktionsappen. Överväg att använda Service Bus-köer för schemalagda meddelanden, begränsa utskalning eller inte använda synlighetTimeout för din lösning.
Azure Cosmos DB
Azure Cosmos DB använder ett attribut på funktionsnivå, MaxItemsPerInvocation. Hur du anger det här attributet på funktionsnivå beror på ditt funktionsspråk.
För en kompilerad C#-funktion anger du MaxItemsPerInvocation i utlösardefinitionen enligt följande exempel för en processbaserad C#-funktion:
namespace CosmosDBSamplesV2
{
public static class CosmosTrigger
{
[FunctionName("CosmosTrigger")]
public static void Run([CosmosDBTrigger(
databaseName: "ToDoItems",
collectionName: "Items",
MaxItemsPerInvocation: 100,
ConnectionStringSetting = "CosmosDBConnection",
LeaseCollectionName = "leases",
CreateLeaseCollectionIfNotExists = true)]IReadOnlyList<Document> documents,
ILogger log)
{
if (documents != null && documents.Count > 0)
{
log.LogInformation($"Documents modified: {documents.Count}");
log.LogInformation($"First document Id: {documents[0].Id}");
}
}
}
}
Kommentar
Eftersom Azure Cosmos DB är en partitionerad arbetsbelastning begränsas antalet målinstanser för databasen av antalet fysiska partitioner i containern. Mer information om Azure Cosmos DB-skalning finns i fysiska partitioner och ägarskap för lån.
Apache Kafka
Apache Kafka-tillägget använder ett attribut på funktionsnivå, LagThreshold. För Kafka beräknas antalet önskade instanser baserat på den totala konsumentfördröjningen LagThreshold dividerat med inställningen. För en viss fördröjning ökar sänkningen av fördröjningströskeln antalet önskade instanser.
Hur du anger det här attributet på funktionsnivå beror på ditt funktionsspråk. I det här exemplet anges tröskelvärdet till 100.
För en kompilerad C#-funktion anger du LagThreshold i utlösardefinitionen, enligt följande exempel för en processbaserad C#-funktion för en Kafka Event Hubs-utlösare:
[FunctionName("KafkaTrigger")]
public static void Run(
[KafkaTrigger("BrokerList",
"topic",
Username = "$ConnectionString",
Password = "%EventHubConnectionString%",
Protocol = BrokerProtocol.SaslSsl,
AuthenticationMode = BrokerAuthenticationMode.Plain,
ConsumerGroup = "$Default",
LagThreshold = 100)] KafkaEventData<string> kevent, ILogger log)
{
log.LogInformation($"C# Kafka trigger function processed a message: {kevent.Value}");
}
Nästa steg
Mer information finns i följande artiklar: