Sitecore Docker Debugging

Image result for dead docker

Having spent the last half year or so diving into docker there’re a few things that I’ve found helpful to understand. Docker can be a lot to wrap your head around if you’re new to containerization, so here are a few of the helpful tips and tricks I came across to help you with Sitecore’s starter kit for Docker(Note, these were findings for sitecore 10.0.0 and 10.0.1).

Unexplained extreme slowness.

Some of the members of my team encountered an issue where Sitecore seemed to be crawling on every request making every aspect of Sitecore extremely slow. Upon further review it was discovered that almost every Sitecore request took an extra 11 seconds almost exactly 11 seconds. The most frustrating part about this is that there was no clues in the logs. It wasn’t until I started systematically removing HttpRequest pipeline providers that I discovered the offending pipeline. The HttpRequest pipeline makes an http request out for some reason or another, disabling this pipeline fixed the issue:

<?xml version="1.0"?>
<configuration xmlns:patch="">
        <processor type="Sitecore.Pipelines.HttpRequest.EnsureServerUrl, Sitecore.Kernel" >
          <patch:delete />

IMPORTANT NOTE! The actual issue was the following:

Unable to attach debugger

A few of my developers encountered an issue where they couldn’t attach to a container. After digging in and analyzing logs from visual studio it lead me to execute this simple test in powershell using .

docker exec -it <docker container name> powershell
iwr -UseBasicParsing

the above resulted in unresolved host


the above resulted in a successful ping output

By these two results combined we could determine that the DNS server wasn’t operating properly for the containers. This specifically impacts attaching a debugger because the first step of attaching a debugger is VS executes docker commands to dynamically download the remote debugging tools into the container using the host name. No DNS, no remote debugging tools, process fails.

    isolation: ${ISOLATION}
        condition: service_started
        condition: service_started

By specifically applying the google DNS server IP this problem was resolved. As a bonus, this also fixed the prior issue.

Memory capped on CM

This one can be sneaky because by default the containers can use up to 1 gig of memory, Sitecore will generally run fine in a container using 1 gig of memory. However, we can do better by designating a higher memory amount if your system has it available. Note that CM, CD, SQL particularly benefit from this adjustment.

    mem_limit: 3GB

In Process isolation

By far the most significant performance boost i could find was to run the Sitecore containers in process. However this can be tricky if you’re not rolling windows server edition. Those of us with Windows 10 Pro need to jump through a few hoops.

  1. Find what windows version you’re running by executing this powershell command

2. Set up your docker-compose file to use the same images as your windows version. In the starter kit this is done in your .env file


Adjust the highlighted text to match your windows version

Winver command confirm Windows 10 version 2004


3. Adjust the process isolation at the bottom of your .env


Now when you start your docker-compose environment it’ll download new images and you’ll be rewarded by environments that use about 40% less memory and 40% more performance. A good situation if you can get it. Note that Sitecore doesn’t have images for every modern windows version, for example if you’re rolling 1909 you won’t be able to run process isolation.