Después de investigar con expertos en el tema, programadores de varias ramas y profesores dimos con la solución al dilema y la dejamos plasmada en esta publicación.
Solución:
Parece que cambiar el nivel de consistencia aumenta enormemente el rendimiento de Symfony. (consulte los documentos de Docker)
Aquí está mi nuevo archivo docker-compose.yml. Tenga en cuenta el “: cached” después de volumne.
version: '3'
services:
web:
image: apache-php7
ports:
- "80:80"
volumes:
- .:/app:cached
tty: true
Nota del manual:
Para directorios montados con caché, la vista del host del sistema de archivos es autorizada; escrituras realizadas por contenedores son inmediatamente visibles para el host, pero puede haber un retraso antes de que las escrituras realizadas en el host sean visibles dentro de contenedores.
Dado que la respuesta proporcionada funciona solo con macOSX, pero existen problemas de rendimiento con Docker para Windows y la respuesta preferida no ayudó en mi caso. Estaba siguiendo un enfoque diferente que se describe parcialmente en las respuestas a preguntas similares aquí en SO.
De acuerdo con las carpetas de Performance Best Practices con mucha carga, como vendor y var en una aplicación Symfony no debería ser parte de un montaje compartido. Si necesita conservar esas carpetas, debe usar volúmenes en su lugar.
Para evitar interferencias con el volumen compartido en /app Estaba reubicando esas dos carpetas en una carpeta separada. /symfony en contenedor. En carpetas de Dockerfile /symfony/var y /symfony/vendor se crean además.
El script que se ejecuta al inicio del contenedor establece enlaces simbólicos desde /app/var para /symfony/var y de /app/vendor para /symfony/vendor. Estas dos nuevas carpetas se montan luego en volúmenes, por ejemplo, en un docker-compose.yml expediente.
Esto es lo que era agregando a mi Dockerfile:
RUN mkdir /app && mkdir /symfony/var,vendor
COPY setup-symfony.sh /setup-symfony.sh
VOLUME /symfony/var
VOLUME /symfony/vendor
Esto es lo que era agregando a mi script de inicio justo antes de invocar composer update o cualquier tarea a través de bin/console:
[ -e /app/var ] || ln -s /symfony/var /app/var
[ -e /app/vendor ] || ln -s /symfony/vendor /app/vendor
Así es como se ve mi composición eventualmente:
version: "3.5"
services:
database:
build:
context: docker/mysql
volumes:
- "dbdata:/var/lib/mysql"
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: 1
application:
depends_on:
- database
build:
context: docker/lamps
ports:
- "8000:8000"
volumes:
- ".:/app:cached"
- "var:/symfony/var"
- "vendor:/symfony/vendor"
environment:
DATABASE_URL: mysql://dbuser:[email protected]/dbname
volumes:
dbdata:
var:
vendor:
Con esta configuración, Symfony responde en 500 ms en lugar de tardar 4000 ms y más.
ACTUALIZAR: Cuando utilice un IDE para desarrollar una aplicación basada en Symfony como PhpStorm, es posible que necesite los archivos en vendedor/ para asistencia de código o similar. En mi caso, pude tomar una instantánea de esos archivos y colocarlos en una carpeta diferente que también se comparte con el host, pero que Symfony / PSR no usa activamente, por ejemplo vendor.dis /. Esta instantánea se toma manualmente una vez por instalación / actualización, por ejemplo, ingresando al contenedor en ejecución con un shell como este:
docker exec -it IDofContainer /bin/sh
Luego en shell invocar
cp -Lr vendor vendor.dis
Tal vez tenga que corregir los nombres de las rutas o asegurarse de cambiar primero a la carpeta que contiene su aplicación.
En mi caso usando PhpStorm el vendor.dis / fue recogido por indexación en segundo plano y obedecido por inspección de código y asistencia de código. El código de Visual Studio tenía problemas con la gran cantidad de cambios sin seguimiento con respecto a git, así que tuve que hacer explícitamente que git ignorara esta instantánea, agregando su nombre en .gitignore expediente.
ACTUALIZACIÓN 2020: Las configuraciones más recientes pueden tener problemas para acceder a carpetas como /symfony/templates o /symfony/public por ejemplo, al calentar la caché. Obviamente, esto se debe al uso de carpetas relativas en el código de carga automática que ahora existe en /symfony/vendor debido a la reubicación descrita anteriormente. Como opción, puede montar directamente volúmenes adicionales en /app/var y /app/vendor en lugar de /symfony/var y /symfony/vendor. Creando copias profundas de esas carpetas en /app/var.dis y /app/vendor.dis sigue habilitando la asistencia de código y las inspecciones en el sistema de archivos del host.
1. no sincronice la carpeta del proveedor
En su archivo de Docker, puede evitar que la carpeta del proveedor se sincronice con el contenedor. Esto tiene el mayor impacto en el rendimiento porque la carpeta se vuelve muy grande:
#DockerFile:
volumes:
- /local/app:/var/www/html/app
- /var/www/html/app/vendor # ignore vendor folder
Esto tendrá el efecto de que necesitará copiar la carpeta del proveedor manualmente al contenedor una vez después de la compilación y cuando actualice las dependencias de su compositor:
docker cp /local/app/vendor :/var/www/html/app/
2. no sincronizar la carpeta de caché
en tus src / Kernel.php:
public function getCacheDir()
3. sincronizar las carpetas de la aplicación en modo delegado
use el modo delegado para montajes de volumen en entornos de desarrollo:
delegado: la vista del contenedor es autorizada (permite retrasos antes de que las actualizaciones del contenedor aparezcan en el host) Ajuste de rendimiento de Docker para montajes de volumen
Esto tiene sentido para dev envrionemtns, porque normalmente cambia su código con su IDE en el host, no en el contenedor, y lo sincroniza con el contenedor. #DockerFile:
volumes:
- /local/app:/var/www/html/app:delegated
4. deshabilitar el modo de depuración de Docker
compruebe si Docker NO está en modo de depuración:
docker info
# It Should display: Debug Mode: false
Desactivar en docker-config:
"debug": false,
5. no utilice una caché de archivos
esto es muy lento en una ventana acoplable, use por ejemplo un caché SQLITE: Symfony Sqlite Cache
Recuerda algo, que tienes la capacidad de reseñar .