"Servidor local" para Symfony en compartida VirtualBOX

geduino

Hola a tod@s.
Os comento un poco mi "problema".
En el trabajo estamos desarrollando la web app con Symfony 3. Con motivo de la lentitud del servidor local que ofrece Symfony, me decidí a montar un servidor apache en un ubuntu server en una máquina virtual con VirtualBox.
La idea era utilizarlo de modo que se puedan ver cambios en tiempo real, para ello monté el proyecto en una carpeta compartida entre mi sistema y el ubuntu server del VBOX. ¡IGUAL DE LENTO!
Por curiosidad, monté el proyecto de forma normal, dentro del ubuntu server, sin compartida ni historias raras y todo como la seda...
El sistema anfitrión que alberga la maquina virtual es Mac... ahí es donde está mi miedo. ¿Es posible que sea el sistema de ficheros de MacOx sea quien realice el proyecto?
La verdad, me gustaría encontrar una solución a esto, ya que estamos condicionando el desarrollo debido a la extrema lentitud del servidor.
Creéis que si el sistema anfitrión fuese un sistema Linux, más en concreto un ubuntu...¿serviría de algo?
Muchas gracias de antemano.

MrTurbo

No tiene que ver, para mejorar el rendimiento en Symfony hay mil y una cosas que puedes hacer. Coméntanos un poco más... ¿versión de PHP?, ¿Tienes instalado APC o algo similar para esa versión de PHP?, ¿Qué paquetes has instalado para tu proyecto en symfony (en composer)?, ¿Están bien montadas las consultas a las entidades? Pásanos un pantallazo del profiler a ver que vemos.

1 1 respuesta
geduino

#2 Hola MrTurbo, gracias por responder.
Como te digo, el rendimiento solo es malo en local, de hecho, en servidor es bastante bueno.
La versión php con la que ejecuto en local el proyecto es 5.6. En el servidor de producción donde funciona a la perfección como te digo se ejecuta bajo la versión 7.
Pero, en el ubuntu server de la maquina virtual, tengo la versión 5.6 y el rendimiento solo se ve perjudicado cuando sitúo el proyecto en la compartida.
Lo que comentas de APC, no tenemos nada instalado. ¿Convendría?
Gracias de nuevo MrTurbo

1 respuesta
MrTurbo

#3 para el de producción no, ya que si tiene PHP 7 es probable que ya tengas el Opcache que viene por defecto. Para PHP 5.6 no sé si viene Opcache, si no yo recomendaría APC o APCu. De todas formas, para desarrollo no es importante el rendimiento (a no ser que sea una barbaridad de lento). Nosotros siempre desarrollamos en nuestros equipos locales y luego hacemos las pruebas y mejoras de rendimiento en un entorno de desarrollo prácticamente idéntico al de producción, para cercionarnos de que la aplicación corra lo suficientemente rápido.

1 2 respuestas
geduino

#4 El problema de rendimiento es sobretodo para los desarrolladores frontend, ya que cada vez que se hace algún cambio tienen que esperar más de unos 30 segundos a que se recargue la pagina... Ya te digo que condiciona mucho a la hora de probar pequeños cambios en vistas (Sobretodo HTML).
Probaré con lo que comentas de APC a ver si consigo mejorar el rendimiento.
Gracias de nuevo.

alterego

No controlo mucho del tema pero si lo tienes montado por NFS puede tardar mucho.
https://www.vagrantup.com/docs/synced-folders/nfs.html

Una opción es montarlo por RSync, sincroniza desde la máquina al vagrant, única dirección.
Tendrás que ejecutar el comando vagrant rsync-auto para que este todo el rato bicheando y sincronizando los ficheros al vagrant.

1 1 respuesta
Traber

¡Buenas! ¿Tienes definido un "open_basedir" en el VHOST? Si es así, y lo tienes en un NFS, el rendimiento te va a ser nefasto, es algo que ya conozco de lidiar hace tiempo con esta mierda, y es debido a que con la directiva "open_basedir" se desactiva "realpath_cache", que es la caché de la que tira PHP a la hora de localizar ficheros en rutas absolutas del sistema operativo. Esto en un script plano no afecta, pero en un framework, que carga varios archivos mediante "include" o "require", tirando así realpath, es cuando se nota el bajón de rendimiento...

En todos los servidores que llevo le acabo metiendo una extensión llamada "realpath_turbo", que es un "bypass" que hace que aunque tengas definido un "open_basedir" en el VHOST la directiva "realpath_cache" no se desactive, tienes más info aquí por si quieres mirarlo:

https://github.com/Whissi/realpath_turbo

P.d.: Tendrás que compilar la extensión, por si no andas muy familiarizado con ello xD.

1 1 respuesta
geduino

#6 #7 Muchas gracias por vuestras respuestas.
La semana pasada estuvimos liados con otros proyectos en los que yo tuve que participar al 100% y no pude dedicarme a esto. Espero sacar algo de tiempo esta semana ya que es algo bastante interesante y todo lo que sea optimización en el desarrollo es vital.
Por lo que comentáis ambos, es un problema de tenerlo montarlo en NFS... Mi duda es... ¿Merece la pena la optimización en este medio? o por el contrario ¿Existen medios alternativos más eficientes?
También puede ser que aquí nos estemos "volviendo locos" con esto, y sea algo normal a la hora de desarrollar con simfony.
Mi tiempo medio de carga en local es de unos 12-15 segundos. Ya sabéis, unas veces arriba y otras por debajo.
¿En que tiempos trabajáis vosotros?

Muchas gracias por vuestro tiempo y vuestra atención.

2 respuestas
MrTurbo

#8 En desarrollo local mis tiempos de carga varían por complejidad de proyectos, pero rondan los 3-4 segundos.

Traber

#8 Realmente, al menos en lo que respecta a mi respuesta, el problema con "open_basedir", los VHOSTS, y la directiva "realpath_cache", es algo que afecta a PHP en general, no solo en sistemas de archivos NFS, pero por lo visto, es más grave y lento aún con dicho sistema de ficheros xD.

En mi caso, me ocurría con mi ordenador de desarrollo y con los servidores de producción, todo con Windows. Fue cuando estaba trabajando en un proyecto con MODX, y los tiempos de carga eran infumables, tras un tiempo tirando del hilo vi que el problema era cuando cargaba archivos mediante include y demás, y comparando directivas con un XAMPP vi que el problema era precisamente el del "open_basedir". Encontré la extensión que te mencioné, y probé con ella... Y el cambio era increíble, se notaba que era eso.

Y no es normal que tarde tanto en cargar, un tiempo aceptable de carga son 3-5 segundos, pero en local debería ser instantáneo, no jodas xD.

Merkury

#4 solo una puntualizacion Opcache y APCu no son para lo mismo, el tener uno no hace automaticamente excluyente el tener el otro.

#1 Una pregunta a que entorno apuntas en el server de desarrollo? Porque si estas cargando dev, es normal que vaya lento por la escritura de la cache de symfony.

Usuarios habituales

  • Merkury
  • Traber
  • MrTurbo
  • geduino
  • alterego