Svarstid i Aktivering
Fabric Activator kör regler mot realtidsdata. Resultaten är nästan omedelbart, men det finns faktorer som kan leda till svarstid. I de flesta fall är svarstiden omärkbar, men i andra fall kan svarstiden vara upp till 10 minuter. Att få korrekt och snabb information är ett viktigt övervägande när du skapar och tar emot regler. Den här artikeln granskar de processer och inställningar som avgör balansen mellan inkludering av händelser och strukturen för en regel och hur snabbt en aktivator skickas. Ska till exempel Activator tillåta att fler data tas emot och inkluderas eller ska Activator se till att mottagarna får sina aviseringar vid en viss tidpunkt? Och hur påverkar det sätt på vilket en regel är strukturerad den hastighet med vilken en aktivering skickas till mottagarna?
Det finns tre viktiga faktorer som påverkar svarstiden för regelaktivering:
- Användarinställningen för tolerans för sena ankomster.
- En fördröjning, upp till en minut, som kan komma att införas av Activators serverdelsbearbetning.
- Sammansättningar för regeln.
Tolerans för sen ankomst
Tolerans för sena ankomster anges på skärmen Aktiveringsregeldefinition och tillämpas på händelsens ankomsttid. Information om hur du anger tolerans för sena ankomster finns i Inställningen för tolerans för sena ankomster.
Svarstid för serverdelsbearbetning
Regler kan behöva bearbetas innan regeln aktiveras. Om regeln till exempel är en jämförelse med en tidigare uppsättning händelser krävs serverdelsbearbetning för att hämta tidigare data, göra jämförelsen och beräkna resultatet. Ett annat exempel är om regeln körs mot 10 miljoner rader data, svarstiden introduceras av serverdelsbearbetningen av dessa data.
Svarstid för sammansättning
Om en aggregering används i regeldefinitionen aktiveras regeln endast när den har slutfört de angivna tidsfönstren. Anta till exempel att en regel har skapats för att genomsnittsdata över fyra timmar. Om en händelse som uppfyller regelvillkoren matas in kl. 12.00 utlöses regeln klockan 16.00. Svarstiden är ett resultat av aggregeringsinställningarna. Även om en regel innehåller en enkel aggregering, till exempel medelvärde, kan Activator inte skicka en aktivering förrän Activator kör aggregeringen över inkommande händelsedata.
Begrepp för bakgrundstid
För att bättre rama in diskussionen ska vi definiera några bakgrundsbegrepp.
- Händelsetid: Den tid då den ursprungliga händelsen inträffade. Det är en del av händelsenyttolasten. Till exempel, när en rörlig bil på motorvägen närmar sig en avgiftsbelagd monter och märkt av en sensor.
- Bearbetningstid: Den tid då händelsen når bearbetningssystemet och observeras. Till exempel när en vägtullssensor ser bilen och datorsystemet tar en stund att bearbeta data.
- Ankomsttid (vattenstämpel eller inmatningstid): En markör som anger när händelsedata når Activator. Av typen av strömmar stoppas aldrig inkommande händelsedata, så ankomsttider anger förloppet som Activator har gjort till en viss punkt i strömmen. Det är i det här läget som Activator kan generera fullständiga, korrekta och repeterbara resultat som inte behöver återkallas. Och det är just nu som Activator kan börja bearbeta data. Bearbetningen kan utföras på ett förutsägbart och repeterbart sätt. Om en omräkning till exempel behöver göras för ett felhanteringsvillkor är ankomsttiderna säkra start- och slutpunkter.
Sen ankomst inträffar när regeln har en tidsparameter och händelsetiden ligger inom den tidsparametern, men ankomsttiden ligger utanför parametern. Om vi använder exemplet med avgiftsbelagda bås igen identifieras bilen av vägtullssensorn och händelsetiden ligger inom tidsparametern. Activator ser att regeln har en aggregering och utför den aggregeringen över data. Den tid det tar att utföra den aggregeringen placerar ankomsttiden utanför tidsparametern. Den händelsen anses nu vara sen. Om du vill att sena ankomster ska inkluderas anger du ett värde för toleransen för sen ankomst.
Ytterligare resurser om detta ämne finns i Tyler Akidaus blogginlägg Streaming 101 och Streaming 102.
Inställning för tolerans för sena ankomster
Tolerans för sena ankomster är en användarinställning. Tolerans för sena ankomster avser hur länge Activator väntar på att en händelse ska anlända och bekräftas och bearbetas. Standardvärdet är två minuter. Tolerans för sena ankomster bidrar till svarstid. Regler som skapas med en tolerans för sena ankomster har en svarstid som är minst den tid som toleransen för sena ankomster är inställd på. När du skapar en regel ska du bestämma om du vill använda standardtoleransen eller ändra den. Tolerans säkerställer att sena händelser och händelser som kommer i fel ordning har möjlighet att tas med i regelutvärderingen. Om en händelse faller utanför toleransen för sen ankomst tar Activator inte hänsyn till den. Händelser med ankomsttid efter den toleransen räknas inte in.
Sammantaget är övervägandet om det är viktigare att:
- Vänta på de sena datapunkterna, eller
- kör regeln på potentiellt ofullständiga data så att regeln aktiveras tidigare.
I det här exemplet mäts datapunkter i steg på 15 minuter. De första tre punkterna, som är blå, gör det i tidsfönstret. Den fjärde punkten, som är orange, gör det inte. Händelsetiden ligger inom intervallet på 15 minuter, men händelsen matas inte in av Activator inom intervallet på 15 minuter. Activator utvärderar endast regeln över data med en ankomsttid inom 15-minutersfönstret. Såvida inte användaren anger att de vill tillåta en tolerans för sen ankomst och vänta för att se om andra datapunkter anländer.
Aktivator kan inte ta hänsyn till fördröjningar från användarens data. Användaren kan till exempel ha IoT-sensorer som är offline i 1 timme. När de är online igen kan Activator ta emot data, men data fördröjdes i 1 timme från offlinetillståndet, vilket sker utanför Activator.
Här är ett annat exempel.
Användaren skapar en regel som beräknar medeltemperaturen i minutintervall. Toleransen för sen ankomst är inställd på Standard. Standardvärdet är två minuter. Temperaturvärdena 20 och 30 ingår och medeltemperaturen är 25. Den sena ankommande händelsen för 40-graderstemperaturen ingår dock inte förrän nästa regelaktivering inträffar.
| Händelsetid | Ankomsttid | Temperatur |
|---|---|---|
| 09:00 | 09:02 | 20 |
| 09:01 | 09:03 | 30 |
| 09:02 | 09:07 | 40 |
Viktigt!
Du kan för närvarande inte åsidosätta standardtoleransen för sena ankomster. Den här inställningen gäller inte heller för Power BI-regler.
Regler som bygger på visuella Power BI-objekt
Den inbyggda svarstiden skiljer sig åt beroende på tjänst. Svarstiden för eventstreams skiljer sig från svarstiden för visuella Power BI-objekt. Det finns två delar som utgör svarstid för regler som bygger på visuella Power BI-objekt: frekvensen för att fråga efter visuella Power BI-objekt som är inbyggda i systemet och en fördröjning som Activators serverdel kan medföra.
Power BI-regler utvärderas när nya data tas emot i Activator. Activator matar in nya data från Power BI varje timme. Det innebär att händelser som uppfyller regelvillkoret utlöser en aktivering högst en timme efter att händelsen inträffar. Mer information finns i Hämta data för Activator från Power BI.