performance - Symfony2 Tiempo de inicialización lento

ubuntu virtualbox

Question

Tengo Symfony2 ejecutándose en una máquina virtual Ubuntu Server 12.04 (64 bits) (VirtualBox). El anfitrión es un MacBook pro. Por alguna razón, estoy obteniendo tiempos de solicitud realmente largos en modo de desarrollo (app_dev.php). Sé que es más lento en el modo dev, pero estoy hablando de 5-7 segundos por solicitud (a veces incluso más lento). En mi Mac obtengo tiempos de solicitud de 200 ms o menos en modo de desarrollo.

Después de mirar mi línea de tiempo en el generador de perfiles Symfony2, noté que ~ 95% del tiempo de solicitud es "tiempo de inicialización". ¿Que es esto? ¿Cuáles son algunas de las razones por las que podría ser tan lento?

Este problema solo se aplica a Symfony2 en modo dev, no a otros sitios que estoy ejecutando en la VM, y ni siquiera a Symfony2 en modo de producción.

Vi esto (http://stackoverflow.com/questions/11162429/whats-included-in-the-initialization-time-in-the-symfony2-web-profiler), pero parece que no responde mis preguntas.

Answer 1

Como se dijo en https://.com/a/12967229/6108843 la razón de tal comportamiento podría ser la configuración de Ubuntu VM. Debe sincronizar la fecha y la hora entre el host y el sistema operativo invitado tal como se explica en https://superuser.com/questions/463106/virtualbox-how-to-sync-host-and-guest-time .

La fecha de modificación del archivo cambia al valor del host cuando carga el archivo a la máquina virtual a través de FTP. Entonces, es por eso que filemtime () devuelve un valor incorrecto.

Answer 2

Descubrí la causa del problema (y no es Symfony2). Por alguna razón en la máquina virtual de ubuntu, los tiempos de modificación en ciertos archivos son incorrectos (es decir, en el futuro, etc.). Cuando symfony2 comprueba estos tiempos utilizando filemtime () en su registro, determina que la memoria caché no está más actualizada y reconstruye todo. No he podido averiguar por qué lo está haciendo todavía.

Answer 3

En app_dev, todas las memorias caché y la carga automática comienzan desde cero y lo que encontré más lento en el desarrollo es el orm. Me niego a usar orm y me concentro principalmente en dbal por eso, aunque probablemente no debería. Orm se usa bastante en sf2. Creo que orm es lo que más te está desacelerando en el desarrollo. Mire la diferencia entre su config dev y prod config. Sin embargo, algunos ajustes a su configuración de desarrollador pueden hacer que el desarrollo sea más ágil y agradable. Solo intente y sea consciente de lo que hace. por ejemplo, apagar el controlador de ramitas y luego modificar muchas plantillas será frustrante. Tu necesidad de seguir limpiando tu caché. Pero como mencionaste, es solo su desarrollador y cuando es hora de que empiece a funcionar, Symfony se acelerará para ti.

Answer 4

Inhabilité xdebug y resultó en un tiempo de carga de disminución de 17 s (sí ...) a 0.5 s.

Answer 5

Puede mover APP/var/cache en /dev/shm/YourAppName/var/cache . Pero también es bueno tener un contenedor construido en archivos locales para la autocompletación IDE y la validación del código. En la app/AppKernel.php :

public function getCacheDir()
{
return $this->getVarOrShmDir(''cache/'' . $this->getEnvironment());
}
public function getLogDir()
{
return $this->getVarOrShmDir(''logs'');
}
private function getVarOrShmDir($dir)
{
$result = dirname(__DIR__) . ''/var/'' . $dir;
if (
in_array($this->environment, [''dev'', ''test''], true) &&
empty($_GET[''warmup'']) && // to force using real directory add ?warmup=1 to URL
is_dir($result) && // first time create real directory, later use shm
file_exists(''/bin/mount'') && shell_exec(''mount | grep vboxsf'') // only for VirtualBox
) {
$result = ''/dev/shm/'' . ''YourAppName'' . ''/'' . $dir . ''/'' . $this->getEnvironment();
}
return $result;
}

Answer 6

También necesitaba deshabilitar xdebug (v2.2.21) para depurar la carga de apache2 max timeout en mi macbook. Fue instalado usando macports:

sudo port install php54-xdebug.

Con xdebug habilitado, cada página se agota al máximo el tiempo de carga, con un error fatal que excede el mensaje máximo de tiempo de espera despachado. Cuando está desactivado, todo se carga bien en un tiempo razonablemente esperado. Llegué a esto usando MAMP, no xdebug habilitado por defecto, y apache2 simplemente funciona rápido como de costumbre. Puedo cambiar para otro depurador, eso es una pena, porque xdebug funcionó bien antes.

Config:

• MacOSX 10.6.8
• macports 2.1.3
• Apache 2.2.24
• php 5.4

Answer 7

También tuve problemas con las cargas lentas de la página en desarrollo, lo que puede ser extremadamente frustrante cuando estás retocando CSS o algo similar.

Después de excavar un poco, descubrí que, para mí, el problema fue causado por Assetic, que estaba recompilando todos los activos en cada carga de página:

http://symfony.com/doc/current/cookbook/assetic/asset_management.html#dumping-asset-files-in-the-dev-environment

Al deshabilitar el uso del controlador Assetic, pude aumentar drásticamente la carga de mi página. Sin embargo, como dice el enlace anterior, esto tiene un costo de regeneración de sus activos cada vez que los modifica (o los vigila).

Answer 8

Tenía respuestas de 5-30 segundos de Symfony2 de forma predeterminada. Ahora es ~ 500ms en entorno de desarrollo.

Luego modifiqué las siguientes cosas en php.ini :

• establecer realpath_cache_size = 4M (o más)
• desactiva XDebug completo (prueba con phpinfo )
• realpath_cache_ttl = 7200
• habilitado y configurado OPcache (o APC) correctamente
• reinició Apache para volver a cargar php.ini

Y voilá, ¡las respuestas fueron menos de 2 segundos en el modo dev! Espero eso ayude.

Antes: 6779 ms

Después: 1587 ms

Symfony2 lee clases de miles de archivos y es un proceso lento. Cuando se usa una pequeña caché de PHP realpath, las rutas de los archivos se deben resolver una por una cada vez que se realiza una nueva solicitud en el entorno de desarrollo si no están en la caché realpath de PHP. La memoria caché realpath es demasiado pequeña por defecto para Symfony2. En prod esto no es un problema, por supuesto.

Metadatos de caché:

El almacenamiento en memoria caché de los metadatos (por ejemplo, mapeos) también es muy importante para aumentar aún más el rendimiento:

doctrine:
orm:
entity_managers:
default:
metadata_cache_driver: apc
query_cache_driver: apc
result_cache_driver: apc

Necesitas habilitar APCu para esto. Es APC sin caché de OPCache ya que OPCache ya almacena en caché los códigos de operación. OPCache está integrado desde PHP 5.5.

---- Después: 467 ms ----

(en el entorno prod la misma respuesta es ~ 80 ms)

Tenga en cuenta que este es un proyecto que utiliza más de 30 paquetes y tiene decenas de miles de líneas de código, casi cientos de servicios propios, por lo que 0.5s es bastante bueno en un entorno local de Windows con solo unas simples optimizaciones.

Answer 9

Tenemos el mismo problema. Aquí tenemos 10 segundos y más para cada solicitud. Veo si elimino las siguientes líneas en bootstrap.php.cache todo el tiempo vuelve en estado normal (298 ms).

foreach ($meta as $resource) {
if (!$resource->isFresh($time)) {
return false;
}
}

Es posible que tengamos tiempos de modificaciones incorrectos, pero no sabemos cómo solucionarlos. Alguien sabe una solución?