-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
V12: Fix ImageSharp3 performance issue #14364
V12: Fix ImageSharp3 performance issue #14364
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 💪
Looking into the ImageSharp.Web source code, computing of the HMAC token doesn't actually require async in the default implementation on @JimBobSquarePants This might be interesting for you too, because the Tag Helper that adds HMAC tokens also uses the sync method. It already short-circuits when the secret is not set, similar to what's now added in Umbraco's Since computing the HMAC token is mostly CPU-bound and fairly quick, it might be better to change |
@ronaldbarendse Thanks for flagging that with me. I don't know why I made What's the expected release date for Umbraco v12? I ask because I need to ship a v3.1 of ImageSharp to fix a critical issue with animated gif generation and the fix contains a breaking change. This would let me also ship a v3.1 of ImageSharp.Web where I could fix this issue properly by removing the async version. Obviously I want Umbraco to be able to ship a working solution before launching v12! I've got some time coming up over the next month to look at getting things shipped as my family are going away but it's still gonna take me a few weeks to get everything done on my own. I don't think it would be possible to squeeze proper performance out of AsyncHelper. It's an abuse to use it in this way anyway. |
May 29, so that pretty soon With breaking changes we should have to wait to Umbraco 13 (december) or make another assembly that uses 3.1 so it becomes available to people to opt in to that. |
It's June 9th just now according to my calendar. This gif issue is really critical. You're gonna get complaints. Likely a lot of them. |
Lol sorry, I cant spell :) June 29. Yes, that's why I suggest we can make a solution in a new assembly that uses 3.1 |
I might be able to make the 29th. I'll try my best. |
You're a ⭐ We'll monitor NuGet :) |
OK. I've opened a PR for the middleware. I'll get stuck into the remaining fixes in ImageSharp main over the next week. |
Hi @JimBobSquarePants . Any update about whether it is realistic or not to have 3.1 released before we release Umbraco 12? |
@bergmania I tried my very best but am struggling to get code reviewed. |
All good, no rush.. We will figure out 😄 |
@JimBobSquarePants We're currently one month away from releasing Umbraco 13 LTS and would really like to take a dependency on the latest ImageSharp.Web that contains the proper fix for this performance issue (PR #327). This would allow us to remove the This is just a 'nice to have' for the 13.0.0 release, as we can always bump the minimum version and fix the code, but I just wanted to check with you if you're planning to release 3.1 soon or if there's other things blocking it (and if so, if we're able to help). |
Sorry for the slow reply @ronaldbarendse It's been a mental time for me lately. I've had to put my head down completely rewriting the gif encoder in ImageSharp plus fixing some significant issues, so the release has come much slower than planned. I can see you've been really helpful in the web discussion repo so thanks for that. I'd really love your insight here also if you can? SixLabors/ImageSharp.Web#339 I've only got a few things to sort now upstream and am planning on a release hopefully by 30th Nov. I'll have a big PR that I'll need someone to help review that fixes and normalizes all animated encoders so if you could help review that I'd be very much obliged. I'll ping you when it's ready. |
During load testing of V12, we noticed that after upgrading to ImageSharp3, sites would occasionally have huge spikes in response times.
Throwing a profiler on it and doing some digging it seems that this is caused by calling
_requestAuthorizationUtilities.ComputeHMAC
in theImageSharpImageUrlGenerator
, the reason for it as far as I can tell is because ImageSharp will use their own utilityAsyncHelper.RunSync
to then run the async method, this, in turn, creates a new Task using theTaskFactory
however, this seems to be causing major hangs. Without knowing the intricate insides ofTaskFactory
I assume that this is caused by some form of thread pool starvation. Changing the code over to_requestAuthorizationUtilities.ComputeHMACAsync(uri, CommandHandling.Sanitize).GetAwaiter().GetResult();
seems to resolve the issue.We can see this pretty clearly from the hotspots in the profiling:
With ImageSharp2:
Looks pretty normal, nothing too out of the ordinary, but if we switch to ImageSharp3:
We see a HUGE spike in time spent on
RunSync
a whopping 35,8% 🤯Now after this patch
We're back to normal, and the spikes are gone when load testing.
Testing