.NET Framework Docker Performance Issue Resolved

[richlander]

.NET Framework Docker Performance Issue Resolved

Multiple people have reported that .NET Framework performance in Docker images is poor. In the cases reported, performance was an order of magnitude slower than expected.

This issue has now been resolved for microsoft/dotnet-framework images. It was due to incorrectly generated NGEN images. They are now correctly generated and expected performance has been restored.

Details

• dotnet-framework-docker #27

The .NET Framework uses NGEN as a primary mechanism for startup performance. .NET Framework assemblies are compiled to native code with the NGEN tool as part of the .NET Framework setup process. The benefit of these files is that they can be loaded and executed without any additional significant extra work required by the Common Language Runtime (CLR). The lack of additional work means that performance is very good.

NGEN image generation interacts with a Windows subsystem that is not correctly supported in Windows containers. NGEN images are generated in Windows containers, but they are not valid. Fortunately, the CLR can still run in the presence of invalid images, but code execution is much slower.

We are in the process of fixing Windows containers so that NGEN will work correctly. In the interim, we have updated the dotnet-framework/ images to correctly generate NGEN images. The microsoft/windowsservercore/ images still have the performance problem that was initially reported. We are working on updating Windows containers so that NGEN works as expected. You are recommended to use the dotnet-framework/ base image if you can, so that you can get better performance.

One of the developers that reported the performance issue shared basic performance results. The first two rows are the before state. The last row is the dotnet-framework image after the fix. The improvement is quite significant.

Runing powershell -command (measure-command { powershell -command exit }).TotalSeconds in various images on our CI server produced this table of timings:

time (s)	image
10.7212372	microsoft/windowsservercore
8.3278793	microsoft/dotnet-framework:4.7
0.6426073	microsoft/dotnet-framework:4.7 (after fix)
0.1642161	microsoft/dotnet-framework:4.7.1-windowsservercore-1709

[g0t4]

I've pulled the latest image docker image pull microsoft/dotnet-framework:4.7 and still have the 10 second startup time. I'm testing this on a Windows 10 machine with version 1703 build 15063.674

[richlander]

Are you referring to the startup time of the image or the number of seconds that the PowerShell command above reports? The startup time of docker run is a different issue. For example, example, docker run -it --rm microsoft/dotnet-framework:4.7 doesn't load/run the CLR, so any startup time there is due to windows containers and the size of the image.

I just re-ran the scenario and see the performance I expected for the PowerShell command.

[richlander]

I updated the table above with the times for the microsoft/dotnet-framework:4.7.1-windowsservercore-1709 image. The following is my test.

Microsoft Windows [Version 10.0.16299.19]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\>powershell -command (measure-command { powershell -command exit }).TotalSeconds
0.1642161

C:\>powershell -command (measure-command { powershell -command exit }).TotalSeconds
0.1477679

C:\>powershell -command (measure-command { powershell -command exit }).TotalSeconds
0.1314013

C:\>powershell -command (measure-command { powershell -command exit }).TotalSeconds
0.1526497

C:\>powershell -command (measure-command { powershell -command exit }).TotalSeconds
0.1507745