Great that this is getting attention now. One major thing you should all do if running on azure is move to nop 3.9, there is a major performance bug fix in the picture service. I discovered this after looking at application insights for a couple of days on nop 3.8. There was a lock statement wrapped around accessing and generating thumbnails. As traffic increased and the server had to hop over to blob storage, all other threads were blocked. Replacing with a mutex and server response went from anything up to 20 seconds down to one second. According to app insights, chatty database calls and requests to blob storage are pretty quick but I still fully advocate the optimisations mentioned here.
Also web apps are just plain slow on connection, ssl and serving up static resources from disk (anything you upload through the back end cams editors) so investigating that next.
Great that this is getting attention now. One major thing you should all do if running on azure is move to nop 3.9, there is a major performance bug fix in the picture service. I discovered this after looking at application insights for a couple of days on nop 3.8. There was a lock statement wrapped around accessing and generating thumbnails. As traffic increased and the server had to hop over to blob storage, all other threads were blocked. Replacing with a mutex and server response went from anything up to 20 seconds down to one second. According to app insights, chatty database calls and requests to blob storage are pretty quick but I still fully advocate the optimisations mentioned here.
Also web apps are just plain slow on connection, ssl and serving up static resources from disk (anything you upload through the back end cams editors) so investigating that next.
It was said here before. Do not use comments to say thanks. Use the correct function to do it. Nobody wants to receive e-mails for each thanks you want to say.
It was said here before. Do not use comments to say thanks. Use the correct function to do it. Nobody wants to receive e-mails for each thanks you want to say.
Please stay focused on the post objective.
Thanks!
And where do you suppose we show our gratitude towards the developers on this topic? And no, it was not stated in this thread before.
We tried "TableNoTracking" before. I do not remember the detail, but we just gave up after many efforts mrx wrote:
They also have a nice feature in IRepository
/// <summary> /// Gets a table with "no tracking" enabled (EF feature) Use it only when you load record(s) only for read-only operations /// </summary>
IQueryable<T> TableNoTracking { get; }
which sould also help load entities faster (for read only / browsing purposes) but I don't see they use it! I could only find 3 places they access with property.
I assume there is big work ahead rewriting all read only queries using this property + calling Include method to make pages less DB chatty. I don't see big problem to optimize existing code to use these two features if you already identified pain points.
Edit: just noticed the thread is about 3.70 version when it was announced big performance improvement in 3.80. I've looked source code from v3.90
Optimising Redis is all well and good if you are running multiple nodes. We have had 2 sites on Azure and neither use Redis. The elephant in the room is the synchronous calls to blob storage to check if thumbnails exist, I've short circuited this problem by caching the existence of the requested thumbnail and using a CDN to deliver them. The general chatty nature of the database calls I've got around by moving everything to an azure VM. It's more admin and you loose the elastic benefits but the site is now blistering fast.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
