18.5. Deactivating the Unused Features

The default symfony configuration activates the most common features of a web application. However, if you happen to not need all of them, you should deactivate them to save the time their initialization takes on each request.

For instance, if your application doesn't use the session mechanism, or if you want to start the session handling by hand, you should turn the auto_start setting to false in the storage key of the factories.yml file, as in Listing 18-19.

Listing 18-19 - Turning Sessions Off, in myapp/config/factories.yml

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

The same applies for the database (as explained in the "Tweaking the Model" section earlier in this chapter) and output escaping feature (see Chapter 7). If your application makes no use of them, deactivate them for a small performance gain, this time in the settings.yml file (see Listing 18-20).

Listing 18-20 - Turning Features Off, in myapp/config/settings.yml

all:
  .settings:
    use_database:      off    # Database and model features
    escaping_strategy: off    # Output escaping feature

As for the security and the flash attribute features (see Chapter 6), you can deactivate them in the filters.yml file, as shown in Listing 18-21.

Listing 18-21 - Turning Features Off, in myapp/config/filters.yml

rendering: ~
web_debug: ~
security:
  enabled: off

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

cache:     ~
common:    ~
flash:
  enabled: off

execution: ~

Some features are useful only in development, so you should not activate them in production. This is already the case by default, since the production environment in symfony is really optimized for performance. Among the performance-impacting development features, the SF_DEBUG mode is the most severe. As for the symfony logs, the feature is also turned off in production by default.

You may wonder how to get information about failed requests in production if logging is disabled, and argue that problems arise not only in development. Fortunately, symfony can use the sfErrorLoggerPlugin plug-in, which runs in the background in production and logs the details of 404 and 500 errors in a database. It is much faster than the file logging feature, because the plug-in methods are called only when a request fails, while the logging mechanism, once turned on, adds a nonnegligible overhead whatever the level. Check the installation instructions and manual at http://www.symfony-project.com/wiki/sfErrorLoggerPlugin.