This is a snippet of code that I’ve used more times than I care to admit, but every time I have to look at my book at https://leanpub.com/epicommercerecipes - the chapter is free and can be read without buying the book. However that is quite inconvenient, so I think it is better if I put it to my blog for later usages - and maybe it helps you too.

For a quite long time, I have a advocate against the use of OR inside the WHERE statement of SQL query.

Cache is good. No, cache is critical - no performant website can go live without proper cache. But can you have too much cache? It turns out that having too much of “good things” can be bad. Sometimes, really bad. In this blog post, let’s explore how too much cache can be a bad thing.

For most developers, the usage of AspNetUsers ends with the APIs - you use the API to create, update, query and delete users - and that’s it. Performance is usually an afterthought, if at all. It’s an official library from Microsoft, it must have good performance, right? I wish I could say, right. As with case of ASPNET Membership (are you old enough to remember it?), this has many performance gotchas. And it can be a huge problem with your website once the number of users have grown enough.

A common table design that you might be familiar with, is to have an identity column, could be int, or long, or uniqueidentifier, and then, a clustered index is conveniently created on that column. An identity is, technically speaking, the perfect choice for clustered index - it is not null, it is unique, and in most case it’s small. But is that really the best choice?

It all started 5 years ago.

Have you ever track and debug a Heisenbug? It’s elusive bug that disappear when you try to find it. But how about the opposite of Heisenbug, the one that tracking the bug actually causes it?

Black Friday is coming, and we are working hard to make sure customers running on Optimizely DXP that anticipating a Black Friday campaign, will be in good shape when the traffic hits. As they say - the optimization season is in full swing. This time, let’s take a case study of how we can identify and optimize a (very) expensive query.

There are things in life that excites and scares you at the same time. Recently I helped out a case when it’s both exciting and scary. The problem was a gigantic 106 GB memory dump with a very small managed heap compared to the dump’s size. That hints unmanaged memory leak. While I’m fairly confident with memory dump analysis, I haven’t had a lot of good luck with unmanaged memory leaks. It could have turned into a big headache and unknown territory. But if it’s not me then who will go to hell? Then game is on.

Why You Should Care About What You Return in Your ScheduledJob.Execute