CHAPTER 11 – Auth Scalability Considerations

Because Auth uses sessions to keep track of logins and PHP stores sessions in local files by default, you will run into problems if you have a site that is being load balanced between several servers. As an example, say that you have a site at www.example.com that is being load balanced between the servers www1 and www2. A user logs in, the POST request with the username and password hits www1, which stores the login information in the Auth session in local files. This means that if the same user submits another request that hits the www2 server, PHP can't find the Auth session on that machine, so it checks the login info through the Auth con- tainer and stores the login information in www2's local session files. So far, so good; seen from the user's point of view, everything is working fine. However, you see two problems: The load on the authentication back-end increases exponentially; the number of Auth checks will become N*M (sessions * servers), as opposed to just N (sessions) for a single-server setup. If you set up sessions to idle-expire, you may experience erratic behavior because the same user could hit only www1 for a series of requests, and when he suddenly hits www2, his session could have expired on that server. You can solve this in a number of ways, all of which have their pros and cons.

Auth Scalability Approach 1: Load-Balancing by Session Id Use a load-balancing system that can use the PHP session id to distribute requests. This ensures that the same session keeps hitting the same server. The only (minor) disadvantage of this solution is that the session will be reset if the des- ignated web server goes down and the load-balancing system sends the user to another server. Auth Scalability Approach 2: Keep Session on Same Server Redi- rect the user to a specific server once the Auth session is set up. In other words, send a Location: header back to the user redirecting him to www2.example.com for the remainder of his session. This is straightforward to implement, but it defeats any failover mechanisms because the user is sending requests directly to a specific server.  

Auth Scalability Approach 3: Common Session Storage Use a dif- ferent session back-end that shares data between all the web servers. This could be everything from a regular database to a session-specific system like msession (available as a PHP extension; see the ext/msession directory in the PHP source tree). Auth Summary Auth is a versatile authentication package for the web environment. You have explored some of its functionality and learned about the advantages and chal- lenges it presents.

Post Comment
Login to post comments