Rendimiento

Symfony2 es rápido, desde que lo sacas de la caja. Por supuesto, si realmente necesitas velocidad, hay muchas maneras en las cuales puedes hacer que Symfony sea aún más rápido. En este capítulo, podrás explorar muchas de las formas más comunes y potentes para hacer que tu aplicación Symfony sea aún más rápida.

Utilizando una caché de código de bytes (p. ej. APC)

Una de las mejores (y más fáciles) cosas que debes hacer para mejorar el rendimiento es utilizar una «caché de código de bytes». La idea de una caché de código de bytes es eliminar la necesidad de constantemente tener que volver a compilar el código fuente PHP. Hay disponible una serie de cachés de código de bytes, algunas de las cuales son de código abierto. Probablemente, la caché de código de bytes más utilizada sea APC

Usar una caché de código de bytes realmente no tiene ningún inconveniente, y Symfony2 se ha diseñado para desempeñarse muy bien en este tipo de entorno.

Optimización adicional

La caché de código de bytes, por lo general, comprueba los cambios de los archivos fuente. Esto garantiza que si cambias un archivo fuente, el código de bytes se vuelve a compilar automáticamente. Esto es muy conveniente, pero, obviamente, implica una sobrecarga.

Por esta razón, algunas cachés de código de bytes ofrecen una opción para desactivar esa comprobación. Obviamente, cuando desactivas esta comprobación, será responsabilidad del administrador del servidor asegurarse de que la caché se borra cada vez que cambia un archivo fuente. De lo contrario, no se verán los cambios realizados.

Por ejemplo, para desactivar estos controles en APC, sólo tienes que añadir la opción apc.stat=0 en tu archivo de configuración php.ini.

Usa la funcionalidad de asociación de clases de Composer

De manera predeterminada, la edición estándar de Symfony2 utiliza el autocargador en el archivo autoload.php. Este autocargador es fácil de usar, ya que automáticamente encontrará cualquier nueva clase que hayas colocado en los directorios registrados.

Desafortunadamente, esto tiene un costo, puesto que el cargador itera en todos los espacios de nombres configurados para encontrar un archivo, haciendo llamadas a file_exists hasta que finalmente encuentra el archivo que estás buscando.

La solución más sencilla es decirle a Composer que construya un «mapa de clases» (es decir, un gran arreglo con la ubicación de todas las clases). Esto se puede hacer desde la línea de ordenes, y se podría convertir en parte de tu proceso de despliegue:

php composer.phar dump-autoload --optimize

Internamente, esto construye el gran arreglo con el mapa de clases en vendor/composer/autoload_namespaces.php.

Memorizando en caché el autocargador con APC

Otra solución es memorizar en caché la ubicación de cada clase después de localizarla por primera vez. Symfony viene con una clase —Symfony\Component\ClassLoader\ApcClassLoader— que hace eso exactamente. Para usarla, sólo adapta tu archivo del controlador frontal. Si estás utilizando la distribución estándar, este código ya debe estar disponible como comentarios en este archivo:

// app.php
// ...

$loader = require_once __DIR__.'/../app/bootstrap.php.cache';

// Usa APC para mejorar el rendimiento de la carga automática
// Cambia 'sf2' por el prefijo que desees a fin de evitar
// conflictos de clave con otra aplicación.
/*
$loader = new ApcClassLoader('sf2', $loader);
$loader->register(true);
*/

// ...

Nota

Al utilizar el cargador automático APC, si agregas nuevas clases, las encontrará automáticamente y todo funcionará igual que antes (es decir, no hay razón para «limpiar» la caché). Sin embargo, si cambias la ubicación de un determinado espacio de nombres o prefijo, tendrás que limpiar tu caché APC. De lo contrario, el cargador aún buscará en la ubicación anterior todas las clases dentro de ese espacio de nombres.

Utilizando archivos de arranque

Para garantizar una óptima flexibilidad y reutilización de código, las aplicaciones de Symfony2 aprovechan una variedad de clases y componentes de terceros. Pero cargar todas estas clases desde archivos separados en cada petición puede dar lugar a alguna sobrecarga. Para reducir esta sobrecarga, la edición estándar de Symfony2 proporciona un guión para generar lo que se conoce como archivo de arranque, el cual contiene la definición de múltiples clases en un solo archivo. Al incluir este archivo (el cual contiene una copia de muchas de las clases del núcleo), Symfony ya no tiene que incluir algunos de los archivos de código fuente que contienen las clases. Esto reducirá bastante la E/S del disco.

Si estás utilizando la edición estándar de Symfony2, entonces probablemente ya estás utilizando el archivo de arranque. Para estar seguro, abre el controlador frontal (por lo general app.php) y asegúrate de que existe la siguiente línea:

require_once __DIR__.'/../app/bootstrap.php.cache';

Ten en cuenta que hay dos desventajas cuando utilizas un archivo de arranque:

  • El archivo se tiene que regenerar cada vez que cambia alguna de las fuentes original (es decir, cuando actualizas el código fuente de Symfony2 o las bibliotecas de proveedores);
  • En la depuración, será necesario colocar puntos de interrupción dentro del archivo de arranque.

Si estás utilizando la edición estándar de Symfony2, los archivos de arranque se reconstruyen automáticamente después de actualizar las bibliotecas de proveedores a través de la orden php composer.phar install.

Archivos de arranque y caché de código de bytes

Incluso cuando utilizas código de bytes en caché, el rendimiento mejorará cuando utilices un archivo de arranque ya que habrá menos archivos en los cuales supervisar cambios. Por supuesto, si esta función está desactivada en la caché del código de bytes (por ejemplo, apc.stat = 0 en APC), no existe una razón para utilizar un archivo de arranque.

Bifúrcame en GitHub