If you are using Optimizely Commerce (Connect, B2C, or whatever you call it these days), you are likely using its serializable cart mode. That cart mode has been introduced 10 years ago (I still remember a cold winter day when I first introduced it to the OMVPs (then EMVPs) at a summit). It was introduced to help reducing the performance issues - most notably deadlocks with order system. Previously, the carts use the same database schema as with the orders, you have base information stored in OrderGroup table and additional, customizable data stored in OrderGroup_ShoppingCart, with a foreign key reference. It works great when it comes to functionality, but when your customer places an order, you need to do two things - saving their order to OrderGroup_PurchaseOrder and delete from OrderGroup_ShoppingCart - as the reference keys are updated in OrderGroup, you risk the chance of deadlock which increasing with your number of carts/orders, and your traffic. Serializable cart mode solved that by moving the cart data to a separate table - and you can probably guess it - SerializableCart. The static fields have their own columns, but the data - which is extendable & customizable - is serialized and stored in Data column.

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. Let’s dive into it to know why you should avoid it, and what is the right solution for it.

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.