I completely agree, I *guess* it would run much faster on a properly designed database. All your queries will be based on an indexed column (session_id). A nice trick would be to create a table that is in memory, this way you would have blazing speed, but then again, you need to study the possibility of the database server going offline and the consequences. Databases are much easier to scale than a file system based solution. And keep in mind if you apply your own session mechanism that doesn't use a database you might run into problems that are very hard to trace/debug (race conditions). You need to test properly with the load you are getting. There are tools to help you simulate the number of sessions that you have.
What you could also do is sharding, which is the technique of splitting the sessions across more than one database. e.g. you can use a hashing function to determine to which Database the session is stored into. As an example: Let's assume you want to create 5 data stores for sessions. Tables might be in the same database or a combination of servers/tables. To make it simple let's say we have the tables sessions1 - session5 in one db. By writing a function that allows sessions to be mapped to their corresponding table, this way you can achieve splitting your number of records by a factor of 5. If you had a million sessions, on average you will have around 200K records in each table. This is a very nice technique for database optimization in general, the draw back is complexity in programming, and if you work on a project with less experienced developers I highly don't recommend sharding all your app. Just minimize it to Sessions, which is gonna be transparent to the developers working on the project as they will be using the built in session mechanism in PHP, and they don't have to worry about what's going on in the background. It wouldn't be hard to benchmark and see the best fit to your problem. - Ammar On Nov 15, 2007 11:38 AM, Zaid Amireh <[EMAIL PROTECTED]> wrote: > > How many concurrent sessions do you have? whats the size of a typical > session file? you have to know your workload to find the best > solution. > > Unless you have 1000+ concurrent sessions the only load you will > imposing on the DB server is the network overhead, sessions come and > go and so the table would stay small, with some extra indexes here and > there you should be golden. > > Then again, even with 1000+ sessions, if the table has proper indexes, > I would assume its still faster than a remote filesystem, too many > factors to write about in this email. > > Zaid > > On Nov 15, 2007 10:12 AM, Ala'a Ibrahim <[EMAIL PROTECTED]> wrote: > > Well, I'm avoiding the use of database, I don't want to add an extra > load on > > the DB server, and don't won't to get a new server for the sessions > > > > > > > > On 11/15/07, Ammar Ibrahim <[EMAIL PROTECTED]> wrote: > > > Database? > > > > > > > > > > > > On Nov 15, 2007 7:48 AM, Ala'a Ibrahim < [EMAIL PROTECTED]> wrote: > > > > > > > Hi, > > > > I'm trying to do a small apache cluster, everything works fine, > except > > for PHP sessions, as they are stored on the filesystem, I tried using an > NFS > > share to hold the data, it worked fine on the testing environment,but on > the > > live servers, it wasn't a good idea, as the NFS share kept hanging up, > so > > I'm thinking of using a DRBD filesystem, connected on all the nodes, > > something like a Replica RAID on all the servers, in the testing > > environment, it worked fine, but I wonder if it would be on the live > one, so > > if anyone thinks this is a bad idea, has a better solution, or has some > > comments please share it. > > > > > > > > Thanks, > > > > > > > > -- > > > > Ala'a A. Ibrahim > > > > http://guru.alaa-ibrahim.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Ala'a A. Ibrahim > > http://guru.alaa-ibrahim.com/ > > > > > > > > > -- > --------------------------- > Netiquette -> http://www.dtcc.edu/cs/rfc1855.html > Netiquette Nazi -> > http://redwing.hutman.net/%7Emreed/warriorshtm/netiquettenazi.htm > --------------------------- > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Jolug" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Jolug?hl=en-GB -~----------~----~----~----~------~----~------~--~---
