• Blog
  • Info Support
  • Career
  • Training
  • International Group
  • Info Support
  • Blog
  • Career
  • Training
  • International Group
  • Search
logo InfoSupport
  • Latest blogs
  • Popular blogs
  • Experts
      • All
      • Bloggers
      • Speakers
  • Meet us
  • About us
    • nl
    • en
    • .NET
    • 3D printing
    • Advanced Analytics
    • Agile
    • Akka
    • Alexa
    • Algorithms
    • Api's
    • Architectuur
    • Artificial Intelligence
    • ATDD
    • Augmented Reality
    • AWS
    • Azure
    • Big Data
    • Blockchain
    • Business Intelligence
    • Chatbots
    • Cloud
    • Code Combat
    • Cognitive Services
    • Communicatie
    • Containers
    • Continuous Delivery
    • CQRS
    • Cyber Security
    • Dapr
    • Data
    • Data & Analystics
    • Data Science
    • Data Warehousing
    • Databricks
    • DataOps
    • Developers life
    • DevOps
    • Digital Days
    • Digital Twin
    • Docker
    • eHealth
    • Enterprise Architecture
    • Event Sourcing
    • Hacking
    • Infrastructure & Hosting
    • Innovatie
    • Integration
    • Internet of Things
    • Java
    • Machine Learning
    • Microservices
    • Microsoft
    • Microsoft Bot Framework
    • Microsoft Data Platform
    • Mobile Development
    • Mutation Testing
    • Open source
    • Pepper
    • Power BI
    • Privacy & Ethiek
    • Python
    • Quality Assistance & Test
    • Quality Assurance & Test
    • Requirements Management
    • Scala
    • Scratch
    • Security
    • SharePoint
    • Software Architecture
    • Software development
    • Software Factory
    • SQL Server
    • SSL
    • Start-up
    • Startup thinking
    • Stryker
    • Test Quality
    • Testing
    • TLS
    • TypeScript
    • Various
    • Web Development
    • Web-scale IT
    • Xamarin
    • All
    • Bloggers
    • Speakers
Home » How the transaction property for WF tracking can make a huge performance difference
  • How the transaction property for WF tracking can make a huge performance difference

    • By Marcel de Vries
    • .NET 14 years ago
    • .NET 0 comments
    • .NET .NET
    How the transaction property for WF tracking can make a huge performance difference

    *Moved to: http://fluentbytes.com/how-the-transaction-property-for-wf-tracking-can-make-a-huge-performance-difference/

    The past two days I have been working on a performance problem we were having with a workflow implementation. The workflow was quite simple, A WCF call coming in, then registering the request data in a SQL database and return a ticket that the request was received. The ticket can be used by people to get information later on the status of their request. (A pretty common SOA pattern)

    The workflow used a TransactionScope activity to guard the persistence of the workflow with the registration call of the custom activity in the database. The workflow runtime had the SqlPersistence service loaded and we use the SqlTrackingService to enable administrators of the system to monitor and see workflow progress of certain requests.

    The time to register a request appeared to be around the 18 seconds per request when we have 20 concurrent users?!? We expected this to be around 1 second Max, depending on the server load.

    After some digging around We detected that if we remove the tracking service the response times where back to what we expected, somewhere around the 0.6 seconds. So how can this happen?

    The answer to this is one very important property that can be set for the tracking service configuration called Transactional. This property was set to false, by one of the developers. This simple setting added around 17 of overhead in SQL communication(with the load we already had on SQL, so can be much less in other specific cases). The property is used to determine if each tracking record that needs to be saved to SQL is done one call at the time or if all work is queued and persisted in one work batch. As you can imagine this will reduce the number of roundtrips to SQL significantly and when the workflow and database server are as busy as with the work we do, times can add up pretty fast.

    So when you see a slow performance in workflow and you have tracking enabled, Look at the transactional property and check if it is not set to false (default is true, so someone would explicitly change this)

    Cheers,
    Marcel

    Follow my new blog on http://fluentbytes.com

    Share this

Marcel de Vries

View profile

Related IT training

Go to training website

Related Consultancy solutions

Go to infosupport.com

Related blogs

  • Building a custom Kubernetes operator in C#

    Building a custom Kubernetes operator in C# Willem Meints - 5 months ago

  • Transform SpecFlow Table Column

    Transform SpecFlow Table Column Ronald Bosma - 7 months ago

  • Building a passwordless login flow with WebAuthn and th…

    Building a passwordless login flow with WebAuthn and th… Willem Meints - 9 months ago

Data Discovery Channel

  • MLOps

  • Explainable AI - Break open the blackbox

  • Toekomstvaste microservice data architecturen

Nieuwsbrief

* verplichte velden

Contact

  • Head office NL
  • Kruisboog 42
  • 3905 TG Veenendaal
  • T +31 318 552020
  • Call
  • Mail
  • Directions
  • Head office BE
  • Generaal De Wittelaan 17
  • bus 30 2800 Mechelen
  • T +32 15 286370
  • Call
  • Mail
  • Directions

Follow us

  • Twitter
  • Facebook
  • Linkedin
  • Youtube

Newsletter

Sign in

Extra

  • Media Library
  • Disclaimer
  • Algemene voorwaarden
  • ISHBS Webmail
  • Extranet
Beheer cookie toestemming
Deze website maakt gebruik van Functionele en Analytische cookies voor website optimalisatie en statistieken.
Functioneel Always active
De technische opslag of toegang is strikt noodzakelijk voor het legitieme doel het gebruik mogelijk te maken van een specifieke dienst waarom de abonnee of gebruiker uitdrukkelijk heeft gevraagd, of met als enig doel de uitvoering van de transmissie van een communicatie over een elektronisch communicatienetwerk.
Voorkeuren
De technische opslag of toegang is noodzakelijk voor het legitieme doel voorkeuren op te slaan die niet door de abonnee of gebruiker zijn aangevraagd.
Statistieken
De technische opslag of toegang die uitsluitend voor statistische doeleinden wordt gebruikt. De technische opslag of toegang die uitsluitend wordt gebruikt voor anonieme statistische doeleinden. Zonder dagvaarding, vrijwillige naleving door uw Internet Service Provider, of aanvullende gegevens van een derde partij, kan informatie die alleen voor dit doel wordt opgeslagen of opgehaald gewoonlijk niet worden gebruikt om je te identificeren.
Marketing
De technische opslag of toegang is nodig om gebruikersprofielen op te stellen voor het verzenden van reclame, of om de gebruiker op een website of over verschillende websites te volgen voor soortgelijke marketingdoeleinden.
Manage options Manage services Manage vendors Read more about these purposes
Voorkeuren
{title} {title} {title}