Long processing time storing data in sagas


(Bheesham Kumar) #1

I created a process using Nservice bus saga. The data is successfully inserting in to DB.
I processed 1500 records. it is inserting in DB but its taking too much time around half an hour. I also use ServiceInsite tool to analysis. I Found, The process time of one record
NserviceBus.Timesent: 2018–01-09 13:51:11 :203663Z
NserviceBus.ProcessingStart : 2018–01-09 14:10:54 :712677Z
NserviceBus.ProcessingEnded : 2018–01-09 14:10:55 :056446Z

For 1500 records, Its taking too much time.
What is the cause of this delay. Please helps us.

(Daniel Marbach) #2

I’m sorry that it is taking so long for messages to be processed. As it looks like the actual processing of that sample message that you posted is fast. It took a while from being sent until it got picked up. Any ideas why? It is a bit difficult to help out without more information. Would it be possible to show us some repro code? You can upload the sample and link it in the thread here or if you have privacy concerns you can also send the zipped sample to support at particular dot net


(Ramon Smits) #3


Which version of NServiceBus are you using? If you are using NServiceBus 5 or earlier then by default messages are processed sequentially and not in parallel.

For NServiceBus 6 and later the default maximum concurrency is equal the number of cores on your machine.

See the following guidance on how to increase the maximum concurrency to allow parallel processing:

Hopefully, this will increase the message throughput and makes sure your backlog of messages is processed much faster taking hopefully seconds instead of half an hour.


(Dennis van der Stelt) #4

Hi, @Bheesham_Kumar

As Daniel already mentioned, the processing is actually pretty fast. What we’re seeing is this:

start : 14:10:54:71
stop  : 14:10:55:05

That means it takes about 0.34 seconds (that’s zero point 34 seconds, not even half a second) to completely process the message.

The issue is that it is sent at 13:51 and only starts processing at 14:10. Perhaps the endpoint was temporarily down or the message was retried with delays or ended up in the error queue and was retried at a later time?