Well, that was the title of my talk at the last week Meetup in Lund – hosted by Avensia. My first time in Lund – it is a very beautiful (small) city. It was a very nice event with about thirty developers from inside and outside Avensia, and I hope I did give some good information to make your Commerce solutions faster!
Then it comes to my attention that some of you might be interested in the talk. Unfortunately I don’t think the talk was recorded (I’d have been famous on Youtube!), but here’s the slides from the talk:
Continue reading “Super charged Episerver Commerce performance”
Recently I wrote about how to look into, identify and solve the problem with a SQL Server execution plan – as you can read here: https://vimvq1987.com/2017/10/curious-case-sql-execution-plan/
I have some more time to revisit the query now, and I realized I made a “small” mistake. The “optimized” query is using a Clustered Index Scan
So it’s not as fast as it should be, and it will perform quite poorly in no cache scenario (when the buffer is empty, for example) – it takes about 40s to complete. Yes it’s still better than the original one, both in non cached and cached cases. But it’s not good enough. An index scan, even cached, is not only slower, but also more prone to deadlocks. It’s also worse in best case scenario, when the original one can use the proper index seek.
Continue reading “A curious case of SQL execution plan, part 2”
I said this, and I will repeat it here: SQL Server optimizer is smart, and I can even say that, generally, it’s smarter than you and me (I have no doubt that you are smart, even very, very smart 🙂 ). So most of the cases, you leave it to do whatever it thinks is the best. But there are cases SQL Server optimizer is fooled by the engine – it gets confused and chooses an sub-optimal plan, because it was given wrong, outdated, or incorrect information. That’s when you need to step in.
Today I face one case like that, as reported here: http://world.episerver.com/forum/developer-forum/Episerver-Commerce/Thread-Container/2017/10/database-timeout-on-productvariant-update/
(As a side note, I don’t answer direct questions, nor provide any personal support service (I would charge plenty for that 😉 ). I would appreciate if you go through World forums, or contact Episerver Developer support service. There are several reasons for that, including knowledge sharing, and work item tracking. I can make exceptions when I know the problem is highly urgent and is hurting your business, by jumping into it sooner than I’m expected to/before it’s escalated through several level of supports. But all in all, it should be registered with Deverloper support. We at development team are supposed to be the final line of support, not the front line. )
Continue reading “A curious case of SQL execution plan”