Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> Date: Thu, 15 May 2008 19:52:20 -0500 > From: <[hidden email]> > Subject: Re: PHP web clusters and session information > To: ref <[hidden email]> > Cc: L-blu <[hidden email]> > Message-ID: <ff7a2c351635d134a265c7840e586bbd@localhost> > Content-Type: text/plain; charset="UTF-8" > > I concur with Richard that the simplest method I have found is to simply > change session.save_path in your php.ini file to an NFS mount. In my own > benchmarks, under a moderate simulated web load with hosts mounted against > the NFS share this performed much better than when trying to use a rather > simple method of storing it in a MySQL back-end (there is of course a lot > of room for optimization on the later which I did not consider at the time > as was looking for simplicity). This seemed to peak at around 6 > concurrent > web hosts against the NFS mount point, though I only had 7 physical hosts > to play with and so don't have insight into the drop-off beyond 7. I can > probably dig out my project paper detailing the specs under this testing > if > you think it might be of benefit to you. > > In theory if you used iSCSI on the back-end for the shared storage with a > clustered file system (I am thinking GFS, as I don't believe OCFS is > designed to perform well with the way PHP stores the session files) you > could scale this well beyond 6 hosts without suffering any performance > degradation. > > If you have the luxury of a BigIP, then you can start to do clever things > such as using embedded cookies to leverage sticky sessions in pinning > someone to a specific host in the cluster, etc. Of course the expense of > such puts out of reach of most open source projects and hobbyists.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |