Man, I'm really sorry, but I don't have such an opportunity like this everyday, I really tried hard but I couldn't help it.
I'M SO SORRY OUR BUSINESS IS MORE SUCCESSFUL THAN YOURS Oh, I feel better now :P Dude, it's not personal, don't take it that way, but your email was my ultimate temptation. Sorry dude On 11/17/07, Zaid Amireh <[EMAIL PROTECTED]> wrote: > > > you kidding me? 200,000 *concurrent* HTTP sessions on *one* server? > whats your session time window? 24 hours? > > seriously mate, if you want help, tell me some thing I would believe. > > Zaid > > On Nov 15, 2007 5:03 PM, Ala'a Ibrahim <[EMAIL PROTECTED]> wrote: > > well, the problem is that it's a legacy system, and we are not planning > to > > do any development on it right now, we are having about 200,000 > concurrent > > sessions on that system, and the database server is also already loaded, > > (given too that the apache server is more loaded) that's why it's being > > clustered upon 2 servers, also the servers are on the same rack, so I > don't > > think the network latency would be a problem. > > > > > > > > On 11/15/07, Ammar Ibrahim <[EMAIL PROTECTED]> wrote: > > > 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 > > > > --------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > 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 > --------------------------- > > > > -- Ala'a A. Ibrahim http://guru.alaa-ibrahim.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
