Aplicación Symfony2 muy lenta en VirtualBox

Ejecuto una copia virtual de Debian en VirtualBox para desarrollar una aplicación PHP de mayor tamaño en una stack nginx / php5-fpm / MySQL. El desarrollo ocurre en el sistema operativo host (Windows 7 x64), el código se monta como una carpeta compartida en el sistema operativo invitado.

El rendimiento es muy malo. Las siguientes son las salidas de webgrind para el sistema de archivos vbox nativo y un assembly samba con cifs:

Perfil vboxfsperfiles smbfs

En cualquier caso, filemtime , file_exists y is_readable tardan varios segundos en ejecutarse. La carga de la CPU es muy alta, el uso de memoria parece normal.

¿La salida de estas tres funciones no se almacena en caché en el caché de estadísticas? ¿Por qué están tomando tanto tiempo?

¡Realmente apreciaría cualquier ayuda que pueda obtener!

Edición: para aclarar, el rendimiento de la producción está bien. En nuestro servidor de pruebas (apropiado, no virtual), el código PHP se ejecuta en ~ 60 ms como máximo en la configuración de producción y en algún lugar entre 100 y 200 ms en modo dev.

Necesito ayuda para descubrir por qué VirtualBox es 100 veces más lento en el modo dev & prod.

Acabo de comprobar, la configuración de producción produce ~ 5sec de ejecución. Aún inutilizable, además de que es incómodo desarrollarlo.

    Utilice nfs para compartir archivos. Samba y el recurso compartido de archivos vbox pueden ser muy lentos.

    Su perfil indica que las operaciones del sistema de archivos son el cuello de botella.

    Lea esta publicación del blog http://clock.co.uk/tech-blogs/virtualbox-404-shared-folder-update para obtener más información

    Recientemente respondí una pregunta similar. Puedes encontrar mi respuesta anterior aquí .

    Voy a hacer un pequeño resumen de ello. No debe medir el rendimiento de su aplicación basándose únicamente en el controlador frontal app_dev.php . Este controlador ha sido creado para ser usado solo para desarrollo. En el desarrollo, realizas muchos cambios en los archivos de configuración, plantillas de twig, recursos, etc. Symfony verificará cientos de archivos en busca de modificaciones y volverá a cargar muchas cosas previamente almacenadas en caché si es necesario, de ahí el alto número de llamadas a filemtime , file_exists y is_readable . Todas estas llamadas se omiten en el modo de producción porque Symfony espera que todo en el caché esté actualizado. Por lo tanto, casi todo lo posible se almacena en caché en el modo de producción y se usa de inmediato sin que Symfony verifique si el archivo ha sido modificado o no. Esto proporciona una gran mejora en el rendimiento porque la carga de un solo archivo en desarrollo puede tomar muchas veces para analizarlo, verificar las dependencias en él, agrupar todo en función de estos archivos, etc.

    Si está comparando su aplicación, evalúela como si estuviera en modo de producción. Al menos, si no puede tener toda la configuración de hardware como espera en producción, siga los siguientes pasos. Borre su caché para el modo de producción y use app.php lugar de app_dev.php . Además, consulte la sección sobre rendimiento que se puede encontrar en symfony.com en la documentación. Aquí la consola llama para limpiar y calentar su caché en el entorno de producción. Creo que cache:clear también calentará el caché, pero como no estoy 100% seguro, prefiero hacer ambas llamadas:

     php app/console cache:clear --env=prod --no-debug php app/console cache:warmup --env=prod --no-debug 

    Espero que esto ayude.

    Saludos, Matt

    Sólo para atar esto:

    Al final, configuré un recurso compartido de samba en el sistema operativo invitado, lo vinculé a un segundo adaptador de red ( solo para host, como en esta guía ) y lo monté como una unidad de red en el sistema operativo host.

    Un poco intrincado, pero los tiempos de ejecución se han reducido a 100-500 ms de 5 a 13 segundos en modo dev con perfiles.

    Además de lo que dijo Matt , te recomiendo que compiles la extensión twig y la utilices como módulo php. Generará plantillas más rápido. Pero aún así, lo más importante es realizar cualquier punto de referencia que ejecute su aplicación en el entorno prod, pero no en dev o test. Asegúrese de no cargar el módulo xdebug en producción, ya que también ralentizará sus puntos de referencia.

    No conozco la configuración exacta, pero lo más probable es que AppCache mejores resultados si instala un proxy inverso adecuado (también conocido como Barniz) en lugar de AppCache para hacer las AppCache solicitudes posibles a la aplicación.

    Tuvo el mismo problema, lo solucioné configurando un cron rsync que mantiene el código en la VM y el host sincronizados.

    Al parecer, las carpetas compartidas de Virtualbox son bastante lentas cuando se trata de leer / escribir archivos: /

    Blogging sobre mi solución en detalle si estás interesado