search

Shuttle / Shuttle.Core.Host

A generic host that can run as a console application or be installed as a Windows service.
BSD 3-Clause "New" or "Revised" License
3 stars 2 forks source link

Shuttle.Core.Infrastructure.ReflectionService Slow Performance #5

Open nicodenysschen opened 4 years ago

nicodenysschen commented 4 years ago

Hi

We are troubleshooting slow performance in our enterprise solution and by using ANTS Profiler we found some issues in the ReflectionService.

We are running version 3.1.6 and we are running .Net 4.6.1. From the release notes it looks like .Net 4.6.1 support was only added later. Would you be so kind to assist with recommendations?

Please see attachment.

Shuttle Core CLIENT_SIT_APP

eben-roux commented 4 years ago

Hi Nico,

How often are you incurring the penalty? That is a rather old bit of code and scanning via reflection is not going to be terribly fast even on a good day.

However, if it is a once-off cost then it may be OK.

I would of course suggest that you upgrade to the most recent version of everything. The new Shuttle.Core.ServiceHost is a bit easier to work with than the old generic host and one can forego some of the scanning an rather explicitly configure certain type, like the queue factories. The latest components all support .Net 4.6.1, .Net Standard 2.0, and .Net Core 2.1.

It may be worthwhile adding logging (through the System.Core.Logging.ILog) interface and setting the log level to VERBOSE to see which files are being scanned. If you have deep hierarchies (and sometimes \backup sub-directories add to this) then all of them will be scanned.

If you need any assistance upgrading, or if you get stuck upgrading, please let me know.

nicodenysschen commented 4 years ago

Thanks Eben

The penalty as you suggested is too high, so I am going to attempt to do an upgrade (Un-Install / Install Latest via Nuget). Only going to install Shuttle.ESB with dependencies as a start.

Will provide feedback.

eben-roux commented 4 years ago

Hi Nico,

There have been quite a number of significant changes to the structure. Please have a look at the documentation to get a feel of what a new implementation would require and then you would need to make the necessary changes to your code. There is a bit of leg-work involved.

IIRC the version you are using may very well still be exactly-once delivery whereas the current version is at-least-once delivery. The handlers also no longer have an IsReusable method (I think that is what it was called). Message handlers are regarded as stateless and reusable by default. There is an IReusability interface that may be implemented on a message handler if required.

The current version also uses a dependency injection container so you would need to pick from one of the six implementations. Other containers may be implemented using the relevant interfaces. If your container of choice is not yet implemented you may log an issue to add one... and I do take pull requests :)