18.5. Desactivando las características que no se utilizan

La configuración por defecto de Symfony activa las características más habituales para las aplicaciones web. No obstante, si no se necesitan todas estas características, es posible desactivarlas para ahorrar el tiempo requerido en inicializarlas durante cada petición.

Si por ejemplo una aplicación no utiliza el mecanismo de las sesiones o si se quiere realizar la gestión de sesiones manualmente, se debería establecer la opción auto_start a false bajo la clave storage del archivo de configuración factories.yml, como muestra el listado 18-19.

Listado 18-19 - Desactivando las sesiones, en frontend/config/factories.yml

all:
  storage:
    class: sfSessionStorage
    param:
      auto_start: false

Lo mismo se puede aplicar a la opción de base de datos (como se explicó en la sección anterior "Optimizando el modelo"). Si la aplicación no utiliza una base de datos, se puede desactivar esta opción para conseguir una ligera mejora en el rendimiento de la aplicación. Estas dos opciones se configuran en el archivo settings.yml (ver listado 18-20).

Listado 18-20 - Desactivando la opción de la base de datos, en frontend/config/settings.yml

all:
  .settings:
    use_database:      off    # Base de datos y modelo

Las opciones de seguridad (ver capítulo 6) se pueden desactivar en el archivo filters.yml, tal y como se muestra en el listado 18-21.

Listado 18-21 - Desactivando algunas características, en frontend/config/filters.yml

rendering: ~
security:
  enabled: off

# generally, you will want to insert your own filters here

cache:     ~
common:    ~
execution: ~

Algunas opciones sólo son útiles durante el desarrollo de la aplicación, por lo que no se deberían activar en producción. Por defecto Symfony optimiza el rendimiento del entorno de producción deshabilitando todo lo innecesario. Entre las opciones que penalizan el rendimiento, el modo de depuración de aplicaciones es la más importante. Los archivos de log de Symfony también se desactivan por defecto en el entorno de producción.

Si los archivos de log se deshabilitan para las peticiones del entorno de producción, puede ser complicado solucionar los errores que se produzcan en este entorno. Afortunadamente, Symfony dispone de un plugin llamado sfErrorLoggerPlugin, que se ejecuta en segundo plano en el entorno de producción y guarda el log de los errores 404 y 500 en una base de datos. Se trata de un método mucho más rápido que los logs tradicionales, ya que los métodos del plugin sólo se ejecutan cuando falla una petición, mientras que el mecanismo de log penaliza el rendimiento en cualquier caso. Las instrucciones de instalación y el manual del plugin se pueden encontrar en http://www.symfony-project.com/wiki/sfErrorLoggerPlugin.