Metodtips för beständighet
Det här dokumentet beskriver metodtips för arbetsflödesdesign och konfiguration som rör arbetsflödesbeständighet.
Design och implementering av varaktiga arbetsflöden
I allmänhet utför arbetsflöden arbete under korta perioder som interfolieras med tider då arbetsflödet är inaktivt eftersom det väntar på en händelse. Den här händelsen kan vara till exempel ett meddelande eller en timer som upphör att gälla. För att kunna ta bort arbetsflödesinstansen när den blir inaktiv måste tjänstvärden bevara arbetsflödesinstansen. Detta är endast möjligt om arbetsflödesinstansen inte finns i en icke-bestående zon (till exempel väntar på att en transaktion ska slutföras eller väntar på en asynkron motringning). Om du vill tillåta att en inaktiv arbetsflödesinstans tas bort bör arbetsflödesförfattaren använda transaktionsomfång och asynkrona aktiviteter endast för kortvariga åtgärder. I synnerhet bör författaren hålla fördröjningsaktiviteter inom dessa no-persist-zoner så korta som möjligt.
Ett arbetsflöde kan bara bevaras om alla datatyper som används av arbetsflödet är serialiserbara. Dessutom måste anpassade typer som används i bevarade arbetsflöden vara serialiserbara för NetDataContractSerializer att bevaras av SqlWorkflowInstanceStore.
Det går inte att återställa en arbetsflödesinstans i händelse av ett värd- eller datorfel om den inte har sparats. I allmänhet rekommenderar vi att du bevarar en arbetsflödesinstans tidigt i arbetsflödets livscykel.
Om arbetsflödet är upptaget under en längre tid rekommenderar vi att du behåller arbetsflödesinstansen regelbundet under den upptagna perioden. Du kan göra detta genom att lägga till Persist aktiviteter i hela sekvensen med aktiviteter som håller arbetsflödesinstansen upptagen. På så sätt leder återanvändning av programdomäner, värdfel eller datorfel inte till att systemet återställs till början av den upptagna perioden. Tänk på att lägga till Persist aktiviteter i arbetsflödet kan leda till försämrad prestanda.
Windows Server App Fabric förenklar avsevärt konfigurationen och användningen av beständighet. Mer information finns i Windows Server App Fabric Persistence
Konfiguration av skalbarhetsparametrar
Skalbarhets- och prestandakrav avgör inställningarna för följande parametrar:
Dessa parametrar bör anges enligt följande, enligt det aktuella scenariot.
Scenario: Ett litet antal arbetsflödesinstanser som kräver optimal svarstid
I det här scenariot bör alla arbetsflödesinstanser förbli inlästa när de blir inaktiva. Ange TimeToUnload till ett stort värde. Användningen av den här inställningen förhindrar att en arbetsflödesinstans flyttas mellan datorer. Använd endast den här inställningen om ett eller flera av följande är sanna:
En arbetsflödesinstans tar emot ett enda meddelande under hela dess livslängd.
Alla arbetsflödesinstanser körs på en enda dator
Alla meddelanden som tas emot av en arbetsflödesinstans tas emot av samma dator.
Använd Persist aktiviteter eller ange TimeToPersist till 0 för att aktivera återställning av arbetsflödesinstansen efter tjänstvärd- eller datorfel.
Scenario: Arbetsflödesinstanser är inaktiva under långa tidsperioder
I det här scenariot anger du TimeToUnload till 0 för att frigöra resurser så snart som möjligt.
Scenario: Arbetsflödesinstanser tar emot flera meddelanden på kort tid
I det här scenariot anger du TimeToUnload till 60 sekunder om dessa meddelanden tas emot av samma dator. Detta förhindrar en snabb sekvens av avlastning och inläsning av en arbetsflödesinstans. Detta behåller inte heller instansen i minnet för länge.
Ange TimeToUnload till 0 och ställ in InstanceLockedExceptionAction på BasicRetry eller AggressiveRetry om dessa meddelanden kan tas emot av olika datorer. På så sätt kan arbetsflödesinstansen läsas in av en annan dator.
Scenario: Arbetsflödet använder fördröjningsaktiviteter med korta varaktigheter
I det här scenariot SqlWorkflowInstanceStore avsöker regelbundet beständighetsdatabasen för instanser som ska läsas in på grund av en aktivitet som har upphört Delay att gälla. Om den SqlWorkflowInstanceStore hittar en timer som upphör att gälla i nästa avsökningsintervall, förkortar SQL Workflow Instance Store avsökningsintervallet. Nästa avsökning sker sedan direkt efter att timern har upphört att gälla. På så sätt uppnår SQL Workflow Instance Store en hög noggrannhet för timers som körs längre än avsökningsintervallet, som anges av RunnableInstancesDetectionPeriod. Om du vill aktivera snabb bearbetning av kortare fördröjningar måste arbetsflödesinstansen finnas kvar i minnet i minst ett avsökningsintervall.
Ange TimeToPersist till 0 för att skriva förfallotiden till beständighetsdatabasen.
Ange TimeToUnload till längre än eller lika med RunnableInstancesDetectionPeriod för att hålla instansen i minnet i minst ett avsökningsintervall.
Vi rekommenderar inte att minska RunnableInstancesDetectionPeriod eftersom detta leder till en ökad belastning på beständighetsdatabasen. Varje tjänstvärd som använder avsöker SqlWorkflowInstanceStore databasen en gång per identifieringsperiod. Om du anger RunnableInstancesDetectionPeriod för litet tidsintervall kan systemets prestanda minska om antalet tjänstvärdar är stort.
Konfigurera SQL Workflow Instance Store
SQL Workflow Instance Store har följande konfigurationsparametrar:
InstanceEncodingOption
Den här parametern instruerar SqlWorkflowInstanceStore att komprimera arbetsflödesinstansens tillstånd. Komprimering minskar mängden data som lagras i beständighetsdatabasen och minskar nätverkstrafiken om beständighetsdatabasen finns på en dedikerad databasserver. Om komprimering används krävs beräkningsresurser för att komprimera och extrahera instanstillståndet. I de flesta fall ger komprimering ökad prestanda.
InstanceCompletionAction
Den här parametern instruerar SqlWorkflowInstanceStore att antingen behålla eller ta bort slutförda instanser. Om du behåller slutförda instanser ökar lagringskraven för beständighetsdatabasen och leder till större tabeller, vilket ökar uppslagstiderna för tabeller. Om inte slutförda instanser krävs för felsökning eller granskning är det bäst att instruera SqlWorkflowInstanceStore att ta bort slutförda instanser. Borttagna instanser bör endast behållas om användaren upprättar en process för att så småningom ta bort dem. Observera att korrelationsnycklar inte kan återanvändas så länge den slutförda arbetsflödesinstansen finns i instansarkivet.
RunnableInstancesDetectionPeriod
Den här parametern definierar det maximala intervall med vilket beständighetsdatabasen SqlWorkflowInstanceStore avsöker för instanser som ska läsas in när en Delay aktivitet upphör att gälla. Om den SqlWorkflowInstanceStore hittar en timer som upphör att gälla i nästa avsökningsintervall förkortas avsökningsintervallet så att nästa avsökning sker direkt efter att timern har upphört att gälla. På så sätt uppnår SQL Workflow Instance Store en hög noggrannhet för timers som körs längre än RunnableInstancesDetectionPeriod.
Vi rekommenderar inte att minska RunnableInstancesDetectionPeriod, eftersom detta leder till en ökad belastning på beständighetsdatabasen. Varje tjänstvärd som använder avsöker SqlWorkflowInstanceStore databasen en gång per identifieringsperiod. Om du anger RunnableInstancesDetectionPeriod ett för litet intervall kan systemets prestanda minska om antalet tjänstvärdar är stort.
HostLockRenewalPeriod
Den här parametern definierar det intervall med vilket värden förnyar sitt lås i beständighetsdatabasen. Om du förkortar det här intervallet kan arbetsflödesinstanserna återställas snabbare om en värd eller dator misslyckas. Å andra sidan ökar belastningen på beständighetsdatabasen en kort period för låsförnyelse. Varje tjänstvärd som använder SqlWorkflowInstanceStore kommer att uppdatera sina lås i databasen en gång per förnyelseperiod. Om en dator kör många tjänstvärdar kontrollerar du att belastningen som orsakas av låsförnyelse inte minskar systemets prestanda. Om det gör det kan du överväga att HostLockRenewalPeriodöka .
InstanceLockedExceptionAction
Om aktiverad försöker återförsöken SqlWorkflowInstanceStore att läsa in en låst instans under de kommande 30 sekunderna. Ange InstanceLockedExceptionAction till BasicRetry eller AggressiveRetry om arbetsflödet tar emot flera meddelanden på kort tid och dessa meddelanden tas emot av olika datorer.
Eftersom mekanismen för återförsök av belastning inte medför några prestandaomkostnader så länge återförsök inte provas, InstanceLockedExceptionAction bör alltid aktiveras.
