Aplicación Symfony2 muy lenta en VirtualBox

Question

Ejecuto una copia virtual de Debian en VirtualBox para desarrollar una aplicación PHP de mayor tamaño en una pila 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. Los siguientes son salidas webgrind para el sistema de archivos nativo vbox y montar una samba con CIFS:

En cualquiera de los casos filemtime, file_exists y is_readable tardar varios segundos para funcionar. La carga de la CPU es muy alta, el uso de la memoria parece normal.

¿La salida de estas tres funciones no está almacenada en caché en la memoria caché de estadísticas? ¿Por qué tardan tanto?

¡Realmente agradecería cualquier ayuda que pueda obtener!

Edit: Para aclarar, el rendimiento de producción está bien. En nuestro servidor de etapas (adecuado, 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-200 ms en modo dev.

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

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

Answer 1

Use nfs file sharing. Samba y el archivo compartido de vbox pueden ser muy lentos.

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

Leer esta entrada del blog http://clock.co.uk/tech-blogs/virtualbox-404-shared-folder-update para una visión más clara

Answer 2

Recientemente he respondido una pregunta similar. Puede encontrar mi respuesta anterior here.

Haré un pequeño resumen del mismo. 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 utilizado solo para el desarrollo. En desarrollo, realiza muchos cambios en los archivos de configuración, plantillas twig, activos, etc. Symfony verificará cientos de archivos para modificaciones y volverá a cargar muchas cosas previamente almacenadas en caché si es necesario, por lo tanto, la gran cantidad 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 la memoria caché esté actualizado. Por lo tanto, casi todo lo posible se almacena en caché en modo de producción y se usa en el futuro sin que Symfony compruebe si el archivo se ha modificado o no. Esto proporciona un gran aumento de rendimiento porque volver a cargar un único archivo en desarrollo puede llevar muchas veces analizarlo, verificar las dependencias del mismo, recapitular todo según estos archivos, etc.

Si está realizando una evaluación comparativa de su aplicación, compárela 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 estos pasos. Borre su caché para el modo de producción y use app.php en lugar de app_dev.php. Además, consulte la sección en performance que se puede encontrar en symfony.com en la documentación. Aquí la consola llama para borrar y calentar su caché en el entorno de producción. Creo cache:clear También habrá de calentamiento la caché, pero como yo no estoy 100% seguro, prefiero hacer las 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

Answer 3

Además de lo dicho Matt recomiendo a compilar la extensión ramita y utilizarlo como módulo php. Generará plantillas más rápido. Pero aún así lo más importante es hacer cualquier punto de referencia ejecutando su aplicación en el entorno de producción, pero no en desarrollo o prueba. Asegúrese de no cargar el módulo xdebug en producción, ya que también ralentizará sus puntos de referencia.

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

Answer 4

Sólo para atar esto:

Al final he creado una parte de la samba en el sistema operativo huésped, con destino a un segundo adaptador de red (host-only, like in this guide) y montado como una unidad de red en el sistema operativo host.

Un poco hacky, pero los tiempos de ejecución son de 100-500ms desde 5-13seg en modo dev con perfilado.

Answer 5

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

Al parecer VirtualBox carpetas compartidas son bastante lento cuando se trata de presentar la lectura/escritura:/

Blogged about my solution in detail if you are interested