1

I have a problem with my publish/subscribe implementation. I'm upgrading from NServiceBus version 2.6 to 4.0.4 and everything seems okay as far as I can understand from the logs but the messages are processed really slowly by the subscriber. I use NServiceBus.Host.exe.

In the old implementation I have configured threads as follows:

<MsmqTransportConfig 
   ErrorQueue="error" 
   NumberOfWorkerThreads="40" 
   MaxRetries="5" />

And the messages go through with nice speed.

In the new implementation I've tried to make the changes needed for the configurations:

<TransportConfig
    MaximumConcurrencyLevel="10"
    MaxRetries="5"
    MaximumMessageThroughputPerSecond="500"/>

Am I missing something critical?

I have a valid license so I should have max threads in use. I haven't got RavenDB or SQL, the implementation uses MSMQ, I've disabled Sagas and TimeoutManager in my subscribers configuration code:

NServiceBus.SetLoggingLibrary.Log4Net(log4net.Config.XmlConfigurator.Configure);
Configure.Features.Disable<Sagas>();

NServiceBus.Configure.With()
   .DefaultBuilder()
   .UseTransport<Msmq>()
   .DisableTimeoutManager()
   .UnicastBus()
   .LoadMessageHandlers();

I did a crude test and the difference in my development environment is so that the 2.6 version handled approximately 80 messages per second and the 4.0.4 version handled approximately 8 messages per second - which is really very bad. So something's wrong here and I just can't seem to find what it is.

Edit: It looks like the problem was generated from our project structure, for some reason the older version of NServiceBus didn't mind our structural approach with generic subsrcriber that uses MEF to load the actual subsrciber-assemblies but the new one went to sleep. I changed the folder structure and now the subscriber works as intended. So the configurations I was using work just fine, but I did delete MaximumMessageThroughputPerSecond from my settings so that it won't present a future problem since the aim is to be as fast as is possible.

user2459400
  • 43
  • 4
  • 1
    You don't need the MaximumMessageThroughputPerSecond if you are trying to run as fast as possible. The locking required to do the math to enforce that limit across so many threads may well be part of your problem. – David Boike Sep 20 '13 at 14:25
  • @David Thanks for the tip! I deleted the unnecessary MaximumMessageThroughputPerSecond from my configuration but the subscriber still works slowly. Logs show that the handling has breaks, like stopping for a moment and then handling few messages at one go and stopping again. This is puzzling for me since the old version doesn't do this. – user2459400 Sep 23 '13 at 11:46
  • When your subscriber starts up, can you check to see what license it is using? i.e. max, or trial or basic? Just to verify that the endpoint is indeed using the license. This should be in the log and its one of the first checks when the endpoint starts up. – Indu Alagarsamy Sep 27 '13 at 17:56

0 Answers0