Sessions, one of those necessary evils when building websites. They come into play whenever you need to have data available between pages on a site. These scenarios typically arise when you have login restricted areas on a site. Why do I refer to them as evil? Quite a few reasons actually but specifically like many good things sessions end up being abused by overloading them with data. Sessions themselves are read and written on every page view (by default) so obviously loading it up with a lot of data can be a performance bottleneck especially as a site scales to millions of page views a day.
When dealing with a login restricted site, all your session really needs to store is the user ID of the user that’s logged in. Everything else you may need about the user can be retrieved from the datastore (database or cache) on demand. Now you’re not lugging around data that could potentially go stale if not kept in sync with changes made to the data in the database. Sessions themselves rely on a cookie that is set in the user’s browser to tell PHP which session to read and write to.
Sessions can be handled in a number of ways, by default they are file-based meaning the session information lives in files on your system’s hard drive in a file. For most cases, this is a sufficient way to handle sessions, but what happens if you have multiple web servers? You could configure your load balancer to use sticky sessions which route traffic back to the same server so they can use the same session. This can be problematic as it can defeat the purpose of a cluster by not allowing you to properly load balance between machines. If a machine is removed from the cluster, the users connected to that server will be logged out of your site. Not an ideal experience.
To deal with the multiple server problem, there are a number of solutions, some more ideal than others. One of my first attempts to handle sessions across multiple servers was to write the sessions to an NFS value that is shared between the servers. This works but it far from efficient under higher volumes specifically in regard to the speed or reading and writing to the share. I’m sure this could be handled by having a faster pipe in between the boxes but there are other options to explore.
What about a datastore? Great idea, PHP supports using Memcached and Redis to store sessions. You could also write your own session handler so you could use something like MySQL or some other datastore that isn’t supported by default. I’m planning on writing another post about using different datastores for sessions so let me just jump to how to use sessions in PHP. To use sessions you have to either enable sessions in the php.ini with the session.auto_start variable or manually starting the session with session_start(). Auto start may not work for you if you plan on running multiple websites on one server and don’t plan on using sessions for all of your sites.
Once the session is started you can interact with the super global array $_SESSION. As I mentioned, you don’t need to nor do I recommend putting too much data in the array. Putting as little as you need in there will keep your sessions small save you some potential headache’s down the road. Tomorrow’s post I’m going to talk about building a simple login system using PHP sessions.
