Moving to the cloud part 2: Enabling database session storage

By default, PHP persists every user session to a single file stored in the system’s default temporary directory. You can go there, open an arbitrary session file – most likely prefixed by sess_ – and you will find a serialized array which represents the contents of the global $_SESSION array which is available to your scripts. Ok, this works great, so what’s the problem with this setup?

Actually, there is nothing wrong with using the file based session storage. But with growing demands some downsides of this approach may attract your attention:

  • The system’s temporary directory is a shared directory: session files of different applications ¬†and temporary files of foreign processes may also use this location. In case of a security issue your user sessions may be compromised. This may be solved by configuring a unique session save path per application and put an open_basedir restriction on top to prevent unauthorized access. This applies all the more if your application is installed on a shared server. In contrast, a database can make use of its access management, you will just need to setup an excluvise account for your session table.
  • There are no simple means to increase file access performance. In constrast, a database usually knows a lot of concepts to improve performance like indexing and clustering.
  • As soon as you want to run your application on multiple servers for reliability and performance reasons you will prefer to store session data in a central location that is common to all webservers. Thus, every webserver shares the same pool of session data and it doesn’t matter which webserver of your cluster serves two subsequent requests of the same client.

Implementing a different session save handler in raw PHP is quite well described in the PHP documentation, so we will focus on how to do the Symfony2 configuration for this requirement. Continue reading “Moving to the cloud part 2: Enabling database session storage”