We are in the process of moving off of the MSMQ transport and over to SQL.
we already use SQL persistence.
we are looking at using a separate catalog for the queues.
we are sharing the connection string across transport and persistence to ensure pooling
The transport produces a warning as we haven’t yet configured Max Pool Size. I can’t seem to find any guidance on determining what this should be - is there anything available? Am I correct in assuming that a value close to the concurrency that the endpoint is running would be suitable?
Assuming you are doing everything necessary to share the SQL connection between the transport, persistence, and any business data modifications you are doing (like is described here) then yes the concurrency level plus a 10-20% buffer should probably be good enough.
Of course assuming your SQL Server can deal, having a few extra above and beyond that for safety is probably fine as well. I’d recommend you add the Application Name property to your connection string as well, so that you can tell on the SQL server via sp_who2 exactly which connections belong to that pool and how many of them are active or idle at any given time. This can give you a good idea of if your configuration to share connection strings is working correctly as well.