Our company has been working over the last months to upgrade 15 NServiceBus endpoints from v3 to v8 using Azure Service Bus transport instead of MSMQ. We are also using Sql Server Persistence layer since our endpoints are outbox enabled. Each endpoint has it’s own database (business data) and the outbox table has been created inside the same db.
We are currently having performance issues and I would like to know if this could be related to poor Outbox configuration. Using Sql Profiler, I can see a lot of maintenance happening on all Outbox tables even though the system is not currently receiving any messages. I also noticed random Sql command timeout with no defined pattern but as soon as I stop debugging my application, everything goes back to normal and queries are no longer timing out.
Our read services are using same EF as before (EF6), they only difference now is the outbox with SQL Server persistence. Any guidelines to follow with these?
To answer your question, we’ll need some more information about your system and logs etc. Can you submit a non-critical support ticket so we can get some more information from you?
One thing I would also suggest to check is the version of the Microsoft.Data.SqlClient. Are you using a reasonably up to date version of that dependency? There have been lots of bugfixes there that are performance related.
That being said like @dan.kent suggested it is probably good to follow up with a support case so that you can send more system details to us.
I did read the guide for Outbox with SQL persistence and I changed the frequence to 24 hours instead of every minute. We will perform more tests to see if our performance improves.
As for Microsoft.Data.SqlClient, we are using System.Data.SqlClient version 4.8.6 (date published=2024-01-09).
Before opening up a support case, I have another question.
Is it ok to have two different endpoints that uses the same DB and their corresponding Outbox is also in the same database? The only reason we have two endpoints instead of one is to separate long processing command (reports) from regular one.
Is something preventing you from upgrading to the more recent 5.x version? I’m just curious to hear because that intel is usually quite helpful for us to better understandt the ecosystem.
It sounds like the split is alongside autonomous components in the same business component. Dennis has a good blog post about this Autonomous Business Components. From that perspective it should be Ok. Sql Persistence uses by default the endpoint name as a table prefix which makes sure things are seperated.
The only thing that might be slightly more complicated I imagine is having to do resource governance should those two autonomous components have wastly different resource requirements on a database level but I’m by no means a SQL expert.