Activities of "Ricavir"

Hi @ismcagdas,

Thank you for your fast answer. I don't think it is a firewall issue as I'm still able to connect with SSMS. Just checked right now without any issue. The latest successful migration has been done 20 days ago with the same machine and same IP address. The migrations that are pending are really simple : just addind few properties to existing tables.

Is it possible that the migration process consumes too much resource to such a point that process cannot ends before a timeout ? Could this be linked with a large amount of data in a table ?

Hi @sedulen,

No, not using Appinsights anymore as the app is running well now. On prod environment, our logging level is set to WARN. I don't have any information to provide about serialization, I'm using default ANZ implementation. Didn't see any issue with it.

Glad to help if I can :)

Hi @sedulen,

I know this is not an easy task to do... be strong :) From our side, we are running on Azure App Service (Windows). App Insights has been very useful to find our main issues, but be careful with its usage, we found that it "costs" on app performance. We heard that it can consume 20 to 25% of performance down ! When we stoped AppInsights, we noticed a gain of more than 50 ms on request time average. Your AWAIT_TIMEs can be caused by the usage of sync calls instead of async. I know that the lastest ABP releases have fixed a lot of that issues. Try to have a look at it !

Cheers

Hi @sedulen

Yes, I have implemented asynchronous JWT token validation. It is better from my side, the app is faster and I'm not having these AWAIT_TIME anymore.

You are pointing out AbpUserTokens, try to reduce the refresh token expiration date et check if this table has not too many records, this can affect you performance.

I also tuned the thread pool count as explained upper on this thread ; this has also improved the app performance.

I don't have used a loading test tool as you did.... but I should :)

Hi @ismcagdas,

Tks for pointing out this issue. I already noticed better performance with projectoin before querrying so that means it will be even better after this resolution.

Hi,

After some research on ABP github repo, I found that automapper projection is already available by using :

var dtos = await ObjectMapper.ProjectTo<EntityDto>(entities)
                .OrderBy(input.Sorting)
                .PageBy(input)       
                .ToListAsync();

The generated SQL is better ; only needed properties are available. This seems to be better also in performance but as fast as my first tests.

@support_team : do you agree that object projection before querying is better than mapping objects after querying ? If so, you should add a note in the docs.

Hi @ismcagdas : I've sent you the files by mail

Hi @sedulen : Thank you for your help. I'm not using hangfire, only using all ABP / ANZ native capabilities. My app has started some years ago and the update process according to current ZERO version is specific. Some time ago, we took the decision to update ABP packages, .NET and Angular only. We only take new ABP features if needed on our side. We stopped updating Metronic theme by version 5 also (as it looks better from our opinion). About background jobs and workers, we are using latests updates from ABP. We always look at the current implementation of ABP team before changing something. All that stuff has been changed from sync to async some months ago. Doing sync stuff is not recommended with latest versions of .NET. This issue is not systematic and is running well most of the time... but sometimes, we are having these logs for background jobs and background workers. I asked ABP team to write some guidelines about multi instance management specialy for theses cases (jobs, workers, cache management...) as it seems to be causing lots of issues...

I can confirm that this error is logged even ef a single instance is running

Currently, the app runs with a single instance. When app is restarted, only one instance is running. We have a scale out rule that switch the app service to 2 or 3 instances according to CPU load but this is not happening frequently.

Hi @musa.demir

Unfortunately, I'm not authorized to send the project. Would it be possible to organize a Teams meeting to share my screen with you ?

The problem can be linked with backgroundworkers our backgroundjobs running with over multiple instances.

I also noticed that this occurs on app restart or after swaping slots in Azure app service.