Hi @omkarchoudhari,
A quick observation - double-check the path to the impersonation endpoint: https://devmovescoutproapi.sirva.com**//**api/TokenAuth/ImpersonatedAuthenticate
that "//" between your domain and the api path segment might be interfering. I've encountered that before.
If that doesn't solve it, what Azure service are you using to host your application? AKS? AppServices? Container Instances? And how are you configured for logging?
You should be able to see what the Internal Server Error is in your application logfiles.
Let me know if that helps, -Brian
Hi @demo.solaru,
I am curious if you tried either of my recommendations in my response. What do you see if you disable Auditing?
In your .Core project, in the PreInitialize() method of your <Project>CoreModule
Configuration.Auditing.IsEnabled = auditLogEnabled; Configuration.Auditing.Selectors.Clear();
I'm mainly curious just to see what the observed behavior is, if that could help the ASPNZ team. I am also curious, if you are running these on your local environment, where all of your resources are.
For the build you are running, is this running the code using the Visual Studio debugger with IIS Express? Or have you built and deployed the code somewhere else?
In a production-like environment, you wouldn't have the overhead of running Visual Studio and JMeter locally on the same machine that is also running your webserver and your database server . Also if you are seeing SQL timeout errors, is your database local as well? Or is the database somewhere else?
My thought is that performance testing can be a bit of a black hole (I know from experience over the last ~2-3 months). You want to establish a reliable baseline, but running everything locally is potentially a skewed test, because everything is running locally on your machine, including programs that wouldn't be involved in a production environment (like Visual Studio and JMeter). The combination of all of those programs all running on 1 machine could yield resource contention which could impact performance.
Lastly - are you running Azure Application Insights? If you are, and you have an Azure subscription, if you could report your telemetry metrics to an Azure Application Insights hosted dashboard that could give you some more insights into exactly what these requests are doing. Azure Application Insights has been a huge help for me for troubleshooting performance-related issues.
Trying to offer ideas. I hope my input helps, -Brian
Hi @pliaspzero
I will be providing my work to the ASPNZ team in the github ticket that @ismcagdas referenced. My project last week took longer than expected, but I finished it up over the weekend, so I should be able to get caught up on your question this week.
-Brian
@Hammer & @ismcagdas
I'd be willing to help with this. I've been using Azure CICD pipelines for several years now and they work great. My project last week took longer than anticipated, but I finished up over the weekend.
I have a few things that I've offered to provide to others, so it may take me a day or two to get back to this, but I will try to get you a generic version of my pipeline that should work for you.
-Brian
Hi @ismcagdas,
Sure - let me see if I can get you a redacted copy of the code that I can share.
I'll follow up in a day or two. -Brian
Hi @pliaspzero,
I have actually implemented something like this in my application. My implementation isn't ideal where I'm using a polling task in the UI to a "GetVersion" endpoint, where I compare the version to a value that is stored in localStorage. If those values don't match, I show an alert that a new version is available, and when they click the OK button, it reloads the window.
The main dependency is that any browser cacheable assets include a cache buster ?d=<value>
I can look at my implementation and see if this is something generic I can offer back to the ANZ community.
Ideally my implementation would have used SignalR & websockets rather than an explicit polling task from the browser, but perhaps the team would be able to make it "right".
Give me a day or two to wrap up something I'm working on now, and I should be able to pull you an example implementation I check for a new version. -Brian
Hi @ismcagdas ,
Just to keep everyone informed, I tried to upgrade our production environment again this weekend, and I think we have run into issues once again and we will be forced to rollback.
At this point I think we can isolate our issue to the EF Core 2 to EF Core 3 breaking changes, specifically the "Cartesean Explosion" https://github.com/dotnet/efcore/issues/18022#issuecomment-542397085 https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-3.x/breaking-changes#eager-loading-single-query
I am looking at our code now, and specifically considering the effort required to upgrade just our dotnet libraries to dotnet core 6 and the latest ABP / ANZ dotnet code.
I will let you know how it goes. -Brian
Thanks @musa.demir.
I will go ahead and post the idea in the github repo this week. -Brian
Please answer the following questions before submitting an issue.
I'm troubleshooting a real weird issue I'm having that seems to be environment related, but I'm not sure why it would be. I deploy using linux docker container images, and I've got a reseller now who's also deploying my application. I have a built docker image that I'm running in ~4 different environments (locally, hosted DEV, hosted UAT, and finally the reseller's hosted UAT)
Locally on my laptop, and in my 2 hosted environments, my app works great. In my reseller's hosted UAT environment, I'm seeing a really strange behavior where the UnitOfWork for the AppService method is Disposing before the EntityCreatingEventHandlers are done. I have logic in my AppService method that tries to optimize how a file is handled. The AppService medthod does some data manipulation using a Stream. When the EntityCreatingEventHandler fires, that file is posted to Azure Blob Storage. But to help keep the filesystem clean, I have attached to the UnitOfWork.Disposed event, where I delete the file from the filesystem.
Looking at my logfiles for where there are issues, the UnitOfWork is Disposing and deleting the file from the filesystem before my EntityCreatingEventHandler completes. I've been very careful to make sure all of my async/await calls are correct, so that I'm not forgetting to await an async call.
What's also very bizarre to me is that the same docker image w/ the same runtime ENV Var configuration would behave correctly in 3 environments, but incorrectly in this 4th environment.
Just to make sure I'm not misunderstanding how this is supposed to work, if I have IEventHandler or IAsyncEventHandler classes that attach to the EntityCreatingEventData<T>, that should execute before my UnitOfWork completes? Is this correct, or am I wrong here?
Thanks! -Brian
Hi @demo.solaru,
I have also been using JMeter to troubleshoot performance-related issues. In my application, I have disabled the AbpAuditLog as it isn't a requirement for me. Instead I have my own explicit Audit Logging, because we need more business-level action tracking that the raw logs that the AbpAuditLog provide.
Can you proceed with your application without the AbpAuditLog?
The other performance issuein the /Token/Authenticate endpoint that I've encountered has been the JwtToken Validation
await _userManager.AddTokenValidityKeyAsync( user, tokenValidityKey, DateTime.UtcNow.Add(expiration.Value)
You do have to store the Token Validity Key in order for the token validation to work correctly.
You can cache the token in your cache (Redis).
Something I had explored was moving the JwtToken store to another datastore, like Azure Tables (I deploy to Azure).
As a performance test, I'm curious if you disable the AbpAuditLog, and then if you comment out the call to _userManager.AddTokenValidityKeyAsync in your TokenAuthController, what your JMeter performance looks like.
I hope that helps, -Brian
