Docker und Performance auf macOS, Linux und WSL verstehen

1. Warum Docker auf verschiedenen Plattformen unterschiedlich schnell ist

Der fundamentale Unterschied in der Docker-Performance zwischen den Plattformen liegt nicht in Docker selbst, sondern in der Isolationsebene darunter. Docker-Container sind keine virtuellen Maschinen – sie teilen sich den Kernel des Host-Betriebssystems. Auf Linux bedeutet das: Container laufen direkt auf dem Host-Kernel, ohne Virtualisierungsebene. Auf macOS und Windows existiert kein Linux-Kernel, also muss Docker Desktop eine Linux-VM starten. Jeder Systemaufruf aus dem Container durchläuft diese Virtualisierungsschicht – mit messbaren Latenzen bei I/O-Operationen.

Die Konsequenzen für die Docker-Performance sind je nach Workload unterschiedlich stark. CPU-intensive Operationen wie Kompilierungen oder Datenbankabfragen sind auf macOS oft nur geringfügig langsamer als auf Linux, weil die Virtualisierungsebene für Prozessoroperationen sehr effizient ist. Der große Unterschied zeigt sich bei Dateisystem-Operationen: Ein PHP-Composer-Install, der tausende kleine Dateien schreibt, oder ein Webpack-Build mit vielen Abhängigkeiten kann auf macOS mit Bind-Mounts dreimal länger dauern als auf Linux. Das Verstehen dieser Ursache ist Voraussetzung für gezielte Optimierungen.

2. Linux: native Performance als Referenzpunkt

Auf Linux ist Docker fast ohne Overhead. Container teilen sich den Host-Kernel, Dateisystem-Operationen laufen über den nativen VFS-Layer, und Netzwerk-Pakete werden direkt über die Linux-Bridge geroutet. Das ist die Referenzplattform, auf der Docker-Performance-Benchmarks üblicherweise gemessen werden. Bind-Mounts sind auf Linux tatsächlich nur Kernel-Mounts: Der Container-Prozess sieht denselben Inode wie der Host, ohne Synchronisierungs-Layer dazwischen.

Selbst auf Linux gibt es Tuning-Möglichkeiten für Docker-Performance. Die Wahl des Storage-Drivers hat Einfluss auf Layer-Operationen beim Image-Aufbau: overlay2 ist der empfohlene Treiber und bietet die beste Balance aus Performance und Kompatibilität. devicemapper ist veraltet und sollte nicht mehr eingesetzt werden. Auf Linux-Systemen mit vielen gleichzeitigen Containern kann das Tuning von Kernel-Parametern wie fs.inotify.max_user_watches und vm.max_map_count relevant sein, insbesondere für Elasticsearch oder andere Memory-Map-intensive Dienste.

# Check current Docker storage driver and performance-relevant kernel params
docker info --format '{ {.Driver} }'          # Should be: overlay2
docker info --format '{ {.MemTotal} }'        # Total memory available to Docker

# Linux: check inotify limits (relevant for file watchers in development)
cat /proc/sys/fs/inotify/max_user_watches   # Default: 8192, often too low

# Increase inotify limit for development environments
sudo sysctl -w fs.inotify.max_user_watches=524288
# Persist across reboots
echo 'fs.inotify.max_user_watches=524288' | sudo tee /etc/sysctl.d/99-docker-dev.conf

# Elasticsearch / OpenSearch: requires higher mmap limit
sudo sysctl -w vm.max_map_count=262144

# Check container I/O stats in real time
docker stats --format "table { {.Name} }\t{ {.CPUPerc} }\t{ {.MemUsage} }\t{ {.BlockIO} }"

3. macOS: Virtualisierung und Dateisystem-Overhead

Docker Desktop auf macOS verwendet Apple's Virtualization Framework (seit macOS 12) oder ältere xhyve/HyperKit-Hypervisoren, um eine Linux-VM zu betreiben. Alle Container laufen innerhalb dieser VM. Das größte Docker-Performance-Problem auf macOS ist die Dateisystem-Synchronisierung zwischen dem macOS-Dateisystem (APFS) und dem Linux-Dateisystem in der VM. Wenn ein Bind-Mount einen macOS-Ordner in einen Container einbindet, müssen Änderungen in beide Richtungen synchronisiert werden – über eine Virtualisierungsgrenze hinweg.

Ältere Versionen von Docker Desktop nutzten gRPC FUSE für diese Synchronisierung, was besonders bei Projekten mit vielen kleinen Dateien extrem langsam war. Ein typisches Magento- oder Symfony-Projekt mit tausenden PHP-Dateien konnte beim ersten Build oder bei der ersten Installation von Abhängigkeiten erheblich langsamer sein. Die Performance-Probleme sind architekturimmanent – kein Docker-Tuning kann den grundlegenden Overhead der Cross-VM-Dateisystem-Synchronisierung eliminieren. Optimierungen können den Unterschied reduzieren, aber nicht auf Linux-Niveau bringen.

4. VirtioFS: der aktuelle Stand des macOS-Dateisystems

VirtioFS ist Apples Implementierung des Virtio-Dateisystemprotokolls, das seit macOS 12.3 in Docker Desktop verfügbar ist und seit Version 4.6 als Standard-Dateisystem-Backend eingesetzt wird. Im Vergleich zu gRPC FUSE bietet VirtioFS erheblich bessere Docker-Performance für Bind-Mounts, weil es tiefer in den macOS-Kernel integriert ist und weniger Overhead pro Dateisystem-Operation erzeugt. Praktische Messungen zeigen für Composer-Installs und Webpack-Builds eine zwei- bis dreifache Verbesserung gegenüber gRPC FUSE.

Trotz VirtioFS bleibt ein messbarer Docker-Performance-Unterschied zu Linux bei schreibintensiven Workloads bestehen. Der empfohlene Ansatz für maximale Performance auf macOS: Abhängigkeiten-Verzeichnisse wie vendor/ (PHP) oder node_modules/ (Node.js) nicht als Bind-Mounts einbinden, sondern als benannte Docker-Volumes anlegen. Docker-Volumes werden ausschließlich innerhalb der Linux-VM verwaltet und sind von der Cross-VM-Synchronisierung befreit. Der Quellcode selbst wird weiterhin als Bind-Mount eingebunden, da Entwickler diesen direkt bearbeiten müssen.

# compose.yml — macOS performance optimization pattern
# Keep source code as bind-mount, dependencies as named volumes
services:
  php:
    image: php:8.4-fpm
    volumes:
      # Source code: bind-mount (developers edit this)
      - ./src:/var/www/html/src:cached
      # Dependencies: named volume (lives entirely inside the Linux VM)
      - vendor:/var/www/html/vendor
      - var:/var/www/html/var
      - generated:/var/www/html/generated

  node:
    image: node:22-alpine
    volumes:
      - ./src:/app/src:cached
      # node_modules as named volume — biggest macOS performance win
      - node_modules:/app/node_modules

volumes:
  # All named volumes live in the VM filesystem, no APFS sync overhead
  vendor:
  var:
  generated:
  node_modules:

# Verify VirtioFS is active in Docker Desktop:
# Settings → General → "Use VirtioFS" must be checked
# docker run --rm -it alpine cat /proc/mounts | grep virtiofs

5. WSL2: zwischen Linux und Windows

WSL2 (Windows Subsystem for Linux 2) bringt einen echten Linux-Kernel unter Windows und bietet damit eine deutlich bessere Basis für Docker-Performance als WSL1. Docker Desktop für Windows nutzt WSL2 als Backend, was bedeutet, dass Container innerhalb der WSL2-Distribution laufen. Wenn Projektdateien im WSL2-Dateisystem (unter /home/ oder /root/) liegen, ist die Performance nahezu identisch mit nativem Linux – weil die Dateisystem-Operationen im Linux-Teil des Systems bleiben.

Das klassische WSL2-Performance-Problem entsteht, wenn Projekte im Windows-Dateisystem gespeichert werden (unter /mnt/c/ oder /mnt/d/) und dann als Bind-Mount in Docker eingebunden werden. In diesem Fall müssen Dateisystem-Operationen die Plan-9-Filesystem-Brücke zwischen dem Windows- und dem Linux-Teil von WSL2 passieren – ähnlich dem macOS-Problem, aber noch langsamer. Die Lösung ist konsequent: Alle Projektdateien, die in Docker-Containern gemountet werden, müssen im WSL2-Dateisystem liegen, nicht im Windows-Dateisystem. Das ist der einzige Weg zu guter Docker-Performance unter WSL2.

6. Bind-Mounts optimieren

Bind-Mounts sind der häufigste Grund für schlechte Docker-Performance in Entwicklungsumgebungen. Die wichtigste Optimierungsmaßnahme ist, den Umfang von Bind-Mounts zu minimieren. Statt das gesamte Projektverzeichnis zu mounten, sollten nur die Verzeichnisse eingebunden werden, die der Container tatsächlich lesen oder schreiben muss. Ein .dockerignore-artiger Ansatz für Compose-Volumes hilft dabei, genauer zu definieren, was gemountet wird.

Für Verzeichnisse, die der Container schreibt (Cache, temporäre Dateien, Build-Artefakte), ist ein benanntes Volume immer performanter als ein Bind-Mount. Das gilt für alle Plattformen, ist aber auf macOS und WSL2-mit-Windows-Dateisystem besonders wirksam. Ein weiteres Tuning-Mittel auf macOS ist das :cached-Mount-Flag – es erlaubt Docker, Reads aus einem Cache zu servieren statt immer direkt mit dem APFS-Dateisystem zu synchronisieren. Seit der Einführung von VirtioFS hat dieses Flag weniger Einfluss als früher, ist aber für ältere Docker-Desktop-Versionen noch relevant.

7. Ressourcen-Limits und Memory-Konfiguration

Docker Desktop auf macOS und WSL2 teilt sich CPU-Kerne und RAM mit dem Host-System. Die Standard-Konfiguration von Docker Desktop reserviert oft weniger Ressourcen als sinnvoll wäre, was zu Swap-Nutzung und damit zu Docker-Performance-Problemen führt. Für Entwicklungsumgebungen mit mehreren Services (PHP-FPM, MySQL, Redis, Elasticsearch) sollten mindestens 6–8 GB RAM zugewiesen werden. Swap im Docker-VM-Bereich ist erheblich langsamer als genutzter RAM und sollte durch ausreichende RAM-Zuweisung vermieden werden.

Unter WSL2 wird die Ressourcenzuweisung über die .wslconfig-Datei im Windows-Benutzerverzeichnis gesteuert. Diese Datei erlaubt das Setzen von Limits für Prozessoren, Arbeitsspeicher und Swap. Eine WSL2-Konfiguration, die Docker ausreichend Ressourcen gibt, ist Voraussetzung für gute Docker-Performance unter Windows. Auf macOS erfolgt die Konfiguration über Docker Desktop Settings, und es gibt keine Konfigurationsdatei auf Dateisystemebene.

# ~/.wslconfig — WSL2 resource configuration for Docker performance
# Place in C:\Users\<username>\.wslconfig on Windows host

[wsl2]
# Allocate sufficient memory for Docker workloads
memory=8GB
# Use half of available CPU cores
processors=4
# Reduce swap to force proper memory allocation
swap=2GB
# Improve kernel network performance
kernelCommandLine=net.ifnames=0

# Apply changes by restarting WSL2:
# wsl --shutdown (in PowerShell)

# Verify resource allocation inside WSL2:
# free -h
# nproc

# Docker compose.yml — resource limits per service
services:
  mysql:
    image: mysql:8.4
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: '2.0'
        reservations:
          memory: 512M

  elasticsearch:
    image: elasticsearch:8.13.0
    environment:
      # Critical: set heap to half of allocated memory
      ES_JAVA_OPTS: "-Xms1g -Xmx1g"
    deploy:
      resources:
        limits:
          memory: 2G

8. BuildKit-Cache und Layer-Optimierung für schnellere Builds

BuildKit ist seit Docker 23 der Standard-Build-Engine und bringt erhebliche Docker-Performance-Verbesserungen gegenüber der klassischen Build-Engine. BuildKit parallelisiert unabhängige Build-Stages, nutzt Cache-Mounts für Paketmanager-Downloads und schreibt nur veränderte Layer auf die Festplatte. Für PHP-Projekte ist der wichtigste Tuning-Hebel der RUN --mount=type=cache-Befehl, der den Composer- oder npm-Cache zwischen Builds persistent hält, ohne den Cache in den Image-Layer zu schreiben.

Ein korrekt aufgebautes Dockerfile mit BuildKit-Cache-Mounts reduziert die Build-Zeit drastisch: Der erste Build installiert alle Abhängigkeiten, alle weiteren Builds nutzen den Cache und laden nur neue oder veränderte Pakete. Die Reihenfolge der Dockerfile-Layer bestimmt, wie effektiv der Cache genutzt wird. Layer, die sich selten ändern (System-Pakete, Basis-Konfiguration), kommen zuerst – Layer, die sich häufig ändern (Anwendungscode, Abhängigkeiten), kommen zuletzt. Eine falsche Layer-Reihenfolge zwingt Docker, bei jeder Code-Änderung alle nachfolgenden Layer neu zu bauen, auch wenn die Abhängigkeiten unverändert sind.

9. Plattform-Performance im Vergleich

Ein fundierter Vergleich der Docker-Performance zwischen den Plattformen muss den Workload berücksichtigen. Reine CPU-Benchmarks zeigen kaum Unterschiede; I/O-intensive Workloads machen die Plattformunterschiede deutlich sichtbar.

Die Prozentzahlen in der Tabelle sind Richtwerte für typische PHP-Entwicklungsumgebungen mit intensiver Dateisystem-Nutzung (Composer, Symfony-Cache, Magento-Codegeneration). Reine Web-Server-Benchmarks ohne Bind-Mounts zeigen deutlich geringere Plattformunterschiede. Das wichtigste Fazit: Die Plattform-Performance ist kein Docker-Problem, sondern ein Dateisystem-Problem – und lässt sich mit den beschriebenen Maßnahmen erheblich verbessern.

10. Zusammenfassung

Docker-Performance ist kein einheitliches Problem – es ist ein plattformspezifisches Problem. Auf Linux gibt es keinen Virtualisierungs-Overhead und Bind-Mounts sind native Kernel-Mounts. Auf macOS erzeugt die Cross-VM-Dateisystem-Synchronisierung den größten Overhead; VirtioFS reduziert ihn erheblich, eliminiert ihn aber nicht vollständig. Die wirksamste Gegenmaßnahme ist, Abhängigkeiten-Verzeichnisse als Named Volumes statt als Bind-Mounts einzubinden. Unter WSL2 hängt die Performance vollständig davon ab, wo die Projektdateien liegen – im WSL2-Dateisystem oder im Windows-Dateisystem.

BuildKit-Cache-Mounts und eine durchdachte Layer-Reihenfolge im Dockerfile reduzieren Build-Zeiten auf allen Plattformen. Ausreichende RAM-Zuweisung an Docker Desktop verhindert Swap-Nutzung, die alle anderen Optimierungen zunichte macht. Mit diesen Maßnahmen lässt sich die Docker-Performance auch auf macOS und WSL2 auf ein für den Entwicklungsalltag akzeptables Niveau bringen – ohne auf Linux wechseln zu müssen.

11. FAQ: Docker Performance auf macOS, Linux und WSL