Jeremy Davis
Sitecore, C# and web development
I've written a few things about diagnosing memory issues in Sitecore over the years, but one topic I've not covered in detail is anything around "how to spot when it's not piles of your own objects that's causing the issue". Problems like leaking handles can have an obvious link back to the custom code that you can spot fairly easily in diagnostic data. But not all memory issues do. I was discussing a possible example of this with a colleague recently, and it seemed like another thing to write down...
When I was writing about dealing with memory analysis for Sitecore recently I focused on a site running under Auzre PaaS. But what if you're working in Docker locally? A good question it turns out...
After my recent delve into memory optimisation for non-work code, I spent some time recently investigating a memory issue in a production Sitecore site. The outcome of that was an issue which can be a common problem for .Net code. So in the hope of seeing it less in the future, here are some notes on what I saw and how you can avoid the same trap...
I spend most of my working life building website code at work, and sometimes I get involved in performance work with that sort of system. In fact I've written and presented on that topic for Sitecore in the past. But some code I've been working on in my own time needs much more focus on code performance than that - the maths-heavy code for ray tracing. I've been looking at some optimisiations for that recently. And one thing that this has reinforced for me is how "easy to write" code can have some performance challenges...
Some time back I did a load of work on performance diagnostic work on some poorly performing Sitecore websites. (Which was the basis of a talk I gave a few times) I've recently had to look at some similar issues - but the world has moved on. I now have Visual Studio 2022 as my diagnostic tool of choice, and the websites are commonly hosted in Azure PaaS web apps. So what do you have to do these days to diagnose likely places for your code to be stuck?
I find myself doing quite a lot of work on performance for Sitecore websites at the moment. Whenever I do a similar job for a group of clients, I start to spot patterns in the sites I'm working on – and it struck me that there are some common performance issues that can be spotted just from the overview graphs you see when you collect trace data.
So to try and help you all improve the sites you ship, here are three that I've come across in a few projects recently:
I got the chance to speak at the Manchester Sitecore user group recently, introducing some tools and tricks that can be used to measure site performance while you're developing your Sitecore code. For anyone who wasn't there (and those who were but, want to refer back to what I said) here's a summary of the important bits of content from that talk...
