How to use CacheTagHelper with content areas in Optimizely CMS 12

Fri, 02 Dec 2022 10:41:34 GMT

I might be going out on a limb here - if you have a better solution, feel very free to share it!

Upgrading your Optimizely web application from .NET Framework to .NET Core should provide a huge performance win. However, the ContentOutputCacheAttribute did not make the cut and was not migrated by Optimizely. If your web application was reliant on this, chances are you had some bottlenecks that will remain even after the upgrade. Not being able to use the output cache attribute will make those bottlenecks come alive once more.

PS. Don't have any bottlenecks? Continue reading anyway - learning how to use CacheTagHelper can dramatically improve your performance.

To once again (shame on you!) hide those bottlenecks, we can pretty easily make use of the CacheTagHelper that .NET Core provides. An unrealistically simple example of this would be:

<cache>
    @Html.PropertyFor(m => m.ContentArea)
</cache>

You've now "solved" one problem (the bottleneck), but gained one new - cache invalidation.

In order to re-evaluate the code block within the cache node - you need to add vary-by-* conditions. Since we're caching a content area, we need to make sure the cache is invalidated whenever visitor groups are applied or when content is published.

Let's first use vary-by to depend on visitor group setup of the content area.

public static string GetContentAreaCacheDiscriminator(this IHtmlHelper htmlHelper, ContentArea contentArea)
{
    var httpContext = htmlHelper.ViewContext.HttpContext;

    if (contentArea == null)
    {
        return httpContext.Request.GetDisplayUrl();
    }

    var requiredRoles = string.Join(",", contentArea.Items.Select(x => x.ContentGroup));

    return $"{httpContext.Request.GetDisplayUrl()}-{requiredRoles}";
}

... and in the Razor view ...

<cache vary-by="@Html.GetContentAreaCacheDiscriminator(Model.ContentArea)">
    @Html.PropertyFor(m => m.ContentArea)
</cache>

The ContentGroup property of every ContentAreaItem in the content area seems to keeps track of what users can see the content.

So, now the cache should be invalidated if visitor groups are applied to the content area.

The ability to re-evaluate the content area whenever some nested block is published is more tricky. The only simple-ish way I can come up with is listening to the publish event, increment some counter and include that counter in the cache discriminator method.

It would look something like this:

public static class AtomicState
{
    public static int Counter = 0;

    public static void Increment() => Interlocked.Increment(ref Counter);
}

[InitializableModule, ModuleDependency(typeof(FrameworkInitialization))]
public class ContentEventsInitializableModule : IInitializableModule
{
    private IContentEvents _contentEvents;

    public void Initialize(InitializationEngine context)
    {
        _contentEvents = context.Locate.Advanced.GetRequiredService<IContentEvents>();

        _contentEvents.PublishedContent += OnPublished;
    }

    public void Uninitialize(InitializationEngine context)
    {
        _contentEvents.PublishedContent -= OnPublished;
    }

    private static void OnPublished(object sender, ContentEventArgs e)
    {
        AtomicState.Increment();
    }
}

Now we must make use of AtomicState.Counter in our cache discriminator method, so just add it to the return statement:

return $"{httpContext.Request.GetDisplayUrl()}-{AtomicState.Counter}-{requiredRoles}";

Since AtomicState.Counter will be read zero or more times per request, and can be updated at any point, we must make it thread safe - which in this case is achieved with Interlocked.Increment(...).

If you wan't more granular control over what cache to invalidate, you need to check the published event for what content type was published and you need another counter for the specific case.

That's it. Thank you for your time! 😏

I originally wrote this post on my personal blog:
https://andreas.jilvero.se/blog/how-to-use-cachetaghelper-with-content-areas-in-optimizely/

Benchmarking Episerver serializable carts

Mon, 26 Jun 2017 10:57:05 GMT

In version 10.2, Episerver introduced a feature called serializable carts. This enables you to store carts as json in a key-value manner to improve performance.

This project aims to benchmark the performance improvements of Episervers new serializable carts system. I will compare:

The old cart helper
The new order repository
The new order repository combined with the serializable carts feature

In order to create good measurements, I will benchmark the same operations performed through the three different cart systems. These operations include:

Create an empty cart and persist it
Add a line item with a meta field to that cart and persist it
Validate the cart and apply campaigns and persist it
Apply payment, process it and persist the cart
Persist the cart as a purchase order

I find it difficult to benchmark only one of these operations at a time, therefore when I execute a step, I also execute the steps prior to that step — i.e. in order to benchmark step 3, I also run step 1 and 2 before.

The source code is available at GitHub. Honestly, you should just continue reading there.

Definition of success

If operations 1 to 3 (the most common operations) are quicker when using serializable carts, I think we can consider it a good improvement.

To measure the performance, I execute the operations in a Web API and stress the API using Apache Benchmark:

ab.exe -c 50 -n 1000 http://localhost:61651/api/cart?operationsToExecute=1

-c 50 indicates 50 clients
-n 1000 indicates the total number of requests

The output of each benchmark will be the time it takes to process 1000 requests.

Results

See the GitHub page for a well-formed table.

	Cart helper	Order repository	Serializable carts
1	00:00:02.910	00:00:03.349	00:00:01.991
2	00:00:04.972	00:00:05.354	00:00:02.534
3	00:00:10.099	00:00:11.883	00:00:04.306
4	00:00:16.519	00:00:16.692	00:00:04.331
5	00:00:20.217	00:00:19.387	00:00:08.422

Conclusions

The results speaks for themselves. Serializable carts performs really well compared to the other two. The newer order repository (without serializable carts enabled) is just as fast/slow as the cart helper. Just getting rid of cart helper namespaces won’t bring you any performance improvements.

I think that serializable carts are mature enough to be used in production, but there are drawbacks though. The serialized cart is stored as json in the database, so if you want to query carts based on some metadata, that will be tricky. If you don’t need to do that, go with serializable carts!

Contribute

I’m no expert in neither benchmarking nor Episerver Commerce and there can be things to improve. Please create a pull request if you think you can improve these benchmarks.

In order to try this yourself, follow the steps below:

Clone repository at GitHub

git clone https://github.com/AndreasJilvero/BenchmarkingEpiserverCarts.git

Create two local SQL server databases and replace the existing connection strings in the web config
Run Episerver SQL install script
```
PM> Install-EPiDatabases
```
Run Episerver SQL update script
```
PM> Update-EPiDatabases
```
Run Star.Epi.CMS
Login as your Windows user
Execute all migration steps
Use Apache Benchmark (or any other tool) to perform requests

Andreas J