Symfony все еще медленно работает в Docker с WSL2 ⇐ Php

[Anonymous]

TL;DR 2:
Годы спустя, продолжая писать проекты Symfony (теперь на Symfony 7.2), я использую Mutagen для синхронизации папки проекта с локальный диск с поддержкой невероятно быстрого твердотельного накопителя 980 EVO Pro 2 для его резервного копирования. Среднее время сократилось с 2–3 секунд на запрос до всего лишь десятых миллисекунд (обычно 70 мс для новой установки).
TL;DR 1:
Через 14 месяцев после того, как я прочитал о выходе WSL2 для Windows (и Docker), я попробовал Symfony 5, и он по-прежнему медленный, как шоколадные шарики.
Еще в первом квартале 2020 года я прочитал о Symfony и Docker работают очень медленно в простой среде настройки. Мы пытались и пытались, но безуспешно: нам не удалось получить Symfony sub 4.000ms, как бы мы ни старались. Одним из решений, очевидно, было перемещение папки поставщика за пределы привязки, управляемой Docker и Window (которая доступна через explorer.exe), и то же самое касается каталога var (для журналов и кеша).
Сейчас второй квартал 2021 года, прошло уже больше года, я переключаюсь между PHP и .NET, но все же хотел попробовать. Я загрузил самую свежую версию Docker Desktop для Windows, которую смог найти, с поддержкой Hyper-V и WSL2. Я установил драйверы поддержки от Microsoft и был готов приступить к работе.
Немного часа спустя, снова просмотрев некоторые данные о том, как на самом деле работает Docker, я быстро развернул PHP 7.4, NGINX. , PostgreSQL, MongoDB и контейнер/стек Redis, и все это работало плавно с помощью простого phpinfo() и нескольких случайных вызовов вышеупомянутых баз данных.
Я установил совершенно новую Symfony 5 и на свой сюрприз, я все еще обнаружил, что проблема осталась. Никакого соединения с базой данных даже не было установлено, и она все равно не работала. Естественно, я упростил свой стек обратно до стека PHP 7.4 и NGINX, надеясь, что где-то я случайно заблудился. К сожалению, меня встретило грубое пробуждение - шоколадные шарики все равно сосут.
Моя установка

Код: Выделить всё

# ./docker-compose.yml
version: '3'

services:
php-fpm:
build:
context: ./php-fpm
volumes:
- ../src:/var/www
networks:
- symfony

nginx:
build:
context: ./nginx
volumes:
- ../src:/var/www
- ./nginx/nginx.conf:/etc/nginx/nginx.conf
- ./nginx/sites/:/etc/nginx/sites-available
- ./nginx/conf.d/:/etc/nginx/conf.d
- ./logs:/var/log
depends_on:
- php-fpm
ports:
- "80:80"
networks:
- symfony

networks:
symfony:

PHP-FPM

Код: Выделить всё

# ./php-fpm/Dockerfile
FROM php:7-fpm-alpine
RUN apk --update --no-cache add git nano
COPY --from=composer /usr/bin/composer /usr/bin/composer
WORKDIR /var/www
CMD php-fpm
EXPOSE 9000

NGINX

Код: Выделить всё

FROM nginx:alpine
WORKDIR /var/www
CMD ["nginx"]
EXPOSE 80

Как вы можете убедиться из моего примера выше, у меня есть папка src, в которой просто и просто хранится установка symfony new src --full со всеми колокольчиками и свистки, предоставляемые базовой установкой - ничего больше.
Единственное решение, которое я смог найти, чтобы моя установка прошла успешно, - это сделать следующее внутри контейнера php-fpm:

Код: Выделить всё

cd /var/www
rm -rf var/
mv vendor ..
ln -s /vendor vendor/
mkdir /var-symfony
chmod 777 /var-symfony
ln -s /var-symfony var/

Хотя я могу просто поместить это в Dockerfile или составить YAML, возникает вопрос: почему этот чертовски медленный, как плавный ду-ду? Я думал, что они могли бы это исправить после, по крайней мере, года множества жалоб.
Я также нашел параметр сетей, который отражен в моем YAML. Это тоже ничего не решило. Возможно, это уменьшит TCP-соединение, поскольку оно TCP, а не напрямую к сокету, но мне еще предстоит попробовать это проверить.
Я читал о некоторых способах создания тома с помощью docker, который частично решает проблему, но не полностью. Это по-прежнему похоже на лоскутное шитье чего-то, что должно работать «из коробки».
Есть ли у кого-нибудь реальный пример использования, где это действительно работает?

Подробнее здесь: https://stackoverflow.com/questions/669 ... -with-wsl2