Slow impacts on Containers view since version 1.23.0

[stormwind85]

I notice some slows on containers view or images view since the new version 1.23.0
I downgraded to 1.22.2 to compare performance and the result is unmistakable !

If I refresh containers view with version 1.22.2, it takes ~ 0.5 sec to refresh containers.
With version 1.23.0, it takes more than 5 sec.

So why ?

Here is my docker version :

Client: Docker Engine - Community
 Version:           20.10.22
 API version:       1.41
 Go version:        go1.18.9
 Git commit:        3a2c30b
 Built:             Thu Dec 15 22:28:04 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.22
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.9
  Git commit:       42c8b31
  Built:            Thu Dec 15 22:25:49 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.13
  GitCommit:        78f51771157abb6c9ed224c22013cdf09962315d
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

I'm also working with a lot of containers, ~ 30 stopped containers in the list and ~ 5 up

[danegsta]

@stormwind85 to help try to reproduce the slowdowns you're seeing, can you provide some additional details on the environment you're running Docker in?

Are you running on Linux, MacOS, or Windows?
What OS version are you on (distro, build number, etc.)?
Is your Docker engine running with default configuration or have you changed any connection settings (connection certificates, Docker engine socket endpoint, etc.)?

[heungson]

I have the same issue. In my case it takes more than 30 secs or maybe minutes to refresh the container list. Docker engine is running on Ubuntu 16.04.7 LTS.
I don't see any problem with Ubuntu 20.04.5 LTS and also with Ubuntu 22.04.1 LTS on WSL

[stormwind85]

@stormwind85 to help try to reproduce the slowdowns you're seeing, can you provide some additional details on the environment you're running Docker in?

Are you running on Linux, MacOS, or Windows? What OS version are you on (distro, build number, etc.)? Is your Docker engine running with default configuration or have you changed any connection settings (connection certificates, Docker engine socket endpoint, etc.)?

I'm running on Ubuntu 22.04.
More details here :

Linux 55K9VN2 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

And yes my docker engine is running with default configuration, I never changed docker default settings.

I also tried on my windows 11 (same VS Code version and latest version of docker extension) but there is no problem. I also have only 2 containers on my Windows so it's not the same deal.

[chrisjimallen]

I'm also experiencing this issue on Fedora 37:

Operating System: Fedora Linux 37 (Workstation Edition)
Kernel: Linux 6.0.12-300.fc37.x86_64
Docker version 20.10.22, build 3a2c30b

[danegsta]

Thanks for providing system details; this will help us in prioritizing the system configurations we start investigating the reported performance bottlenecks against.

[lennertcc]

Same problem here. Thanks for investigating.

Linux fedora 6.0.12-1.surface.fc37.x86_64
Docker version 20.10.22, build 3a2c30b

Upgraded to Fedora 37 last week, problem existed already before that, when I was still on Fedora 36.

[ahmed2m]

I have thee same problem on Manjaro.

Kernel: 5.17.9-1-MANJARO x86_64
Docker version 20.10.22, build 3a2c30b63a

[ahmed2m]

Update: this also happens in github codespaces with the docker extension

[chrisjimallen]

This is still occurring for me. Latest Fedora 37 packages. I do have about 10-15 different containers, albeit only 1 or 2 running simultaneously. Speculation, but perhaps number of 'installed' containers is a factor?

[nemec32039]

Hi, I figured out the reason why the container listing is loading slowly. The problem is in the speed of finding the container size.

On the environments I have tested, the command docker container ls --no-trunc --all --format '{{json .}}' is very slow (tens of seconds).

The problem is that {{json .}} always calculates the size of the docker container. This causes time delays if there are multiple containers and they are large. In my environment I have several containers that have hundreds of MB.

Proposal for a solution:

It is necessary to extract the Size value from the container listing example. I don't know if container size is used anywhere in the listing. I found a constant withDockerJsonFormatArg in the code.

I tested:

export const withDockerContainerJsonFormatArg = withNamedArg('--format', `{"Command":{{json .Command}},"CreatedAt":{{json .CreatedAt}},"ID":{{json .ID}},"Image":{{json .Image}},"Labels":{{json .Labels}},"LocalVolumes":{{json .LocalVolumes}},"Mounts":{{json .Mounts}},"Names":{{json .Names}},"Networks":{{json .Networks}},"Ports":{{json .Ports}},"RunningFor":{{json .RunningFor}},"Size":"undetected","State":{{json .State}},"Status":{{json .Status}}}`);

I'm not sure of the implications of this.

And in the getListContainersCommandArgs method in the file DockerClientBase.ts, I replaced the constant.

I'm testing it right now and so far no signs of any issue.

docker/for-linux#1179
#3821

[chrisjimallen]

@nemec32039 Does it look like its a problem with the VScode extension, or docker on Linux?

[nemec32039]

@chrisjimallen This is not problem with VScode extenstion but neither docker. The VScode extension needs optimization for loading data for container listing.

I think the extension is loading more data than it needs to. Slow loading causes waiting to find out the size of containers. This information is not needed for container listing.

[ahmed2m]

But it's definitely related to a change done between 1.22.x and 1.23.0 because I don't have the problem with 1.22.x versions

[nemec32039]

@danegsta

PoC
nemec32039@9f3a7c9

Omitting fields from command for containers data. They are not needed. "Command" "LocalVolumes" "Mounts" "RunningFor" "Size"

[danegsta]

@nemec32039 we originally did do more targeted format arguments in our initial implementations of the new Docker client logic that shipped in 1.23.0, but had to revert to using '{{json .}}' in this PR. Unfortunately, if a property that doesn't exist on a given item is ever requested as part of the format string, it results in an error from the Docker CLI. This is particularly an issue when dealing with supporting older Docker releases. Additionally, we've run into issues where (for at least some Docker configurations), required properties are included in the default '{{json .}}' format response that aren't actually available to request as individual properties.

Effectively, this means we have to depend on --format '{{json .}}' to avoid breaking the extension entirely for some users. We'll bring up the docker/for-linux#1179 issue with any contacts we have at Docker, Inc. to try to get a fix for the underlying issue prioritized as it's obviously causing a significant performance impact.

[bwateratmsft]

A --size=false flag has been added to upcoming Docker CLI releases that we can leverage to skip the size computation. Based on this comment, we should be able to unconditionally pass --size=false, with older versions of the CLI simply ignoring it.

[chrisjimallen]

@bwateratmsft as of right now, would you recommend just rolling back to an older version (1.22.x) for those who are suffering this issue? I was wondering what kind of ETA we are looking at for a resolution?

[bwateratmsft]

We plan to ship an update (1.25.0) containing this fix sometime in the next few weeks, but it also requires upgrading Docker to a version containing the fix for docker/for-linux#1179. They have merged in a fix but I'm not sure how long until it reaches GA, they would have to answer that. Since switching extension versions in VSCode is painless, I'd say yes, roll back to 1.22.x for now; you can catch back up at any time.

[stormwind85]

Hello !
Could you please make the release of 1.15.0 milestone ?

[alexyaang]

This has now been released in Docker extension version 1.25.0. However, keep in mind that this will only work if Docker releases their fix as well. docker/cli#4107 (comment)

[stormwind85]

Well, I just want to give a little feedback and it works as fast as it did on version 1.22.2 (latest version before this issue).
Great job 😃

[bwateratmsft]

That's great! Glad to hear it's working better now.