Hi Zaid, I' so sorry again, but if I didn't say it I wouldn't be sleeping for days :), thanks for the complement, or whatever it was.
anyway back to business, this number I got from the system admins, I don't work on that machine, and I don't really know if it's true or not, but I'm sure this is not happening 24 hours, but as far as I know, it reaches something like this during the day, and I also guess there is something wrong with your calculation. let's start by, everytime apache is installed we make sure to change the max simultaneous connections is changed to 1024, and once again it's not RPS, it's the number of requests that can be handled simultaneously, also, for me I've worked on optimizing stuff, and without playing with the OS, only PHP, Apache, and of course with APC. I managed with an AMD 64 Athlon processor to get a php application that was launched online, to take it up to about 15,000 RPS, also dude, if it takes 1 sec for each page to respond, I guess you are in deep trouble. Also the use of client caching is so important, I don't think that anybody takes the css, JS, and images files, every time the browser makes a request, this would be so waste of bandwidth, that's why we use Expires, Last-Modification-Date, and the E-Tag headers sent, so the user won't get the same data twice, so mostly in the end, the user in most of the times just gets the HTML. also given that we have the DB on another machine, that would remove it's burden from the sever, it's on another server on the same Rack. and don't think that even when reaching that number the server is standing doing his job well, it would be dying out there, and that's why there is the need for another machine to share this burden with. So for me I guess 200,000 is so believable to have, just after doing a good job. On 11/17/07, Zaid Amireh <[EMAIL PROTECTED]> wrote: > > Dear Ala'a, > > You are a smart guy whom I respect. I am not going to reply to your > highlighted bold comment for obvious maturity reasons :) , on the > other hand, the number you claimed (200,000) is beyond absurd and > following is my explanation: > > In PHP, the default value of session.gc_maxlifetime in 1440 seconds, > which equals 24 minutes, I will assume that your clients are browsing > 3 pages during their session lifetime which is a very low number, but > stick with me, it gets interesting. > > 200,000 * 3 = 600,000 page requests in 24 minutes. > > each page would contain an average of 5 media elements, also way too > low but I'm not gonna stress test you here, so we end up with 6 > requests for each page. > > so 600,000 * 6 requests served in 24 mins = ( (600,000 * 6) / (24*60) > ) thats 2500 requests per second. > > You do know that apache's default of MaxClients (which is max > concurrent requests if you don't have keep alive on) is 256 and that > you have to change the source code to increase that, right? ever > wondered why its hard coded at 256? > > lets assume you did increase the cap and you are happily serving 2500 > RPS, I don't know what hardware or software you have, but I can > extrapolate on the environment that I operate since its all php and > apache after all. > > I have a dual core Xeon with 2 gigs of RAM, hardware RAID 1, 100mbits > uplink, its a decent Dell PowerEdge machine that has been grinding web > requests for the last couple of years, it took me 2 months to fully > tweak the OS and applications, starting from the VM parameters in the > kernel, to the TCP params in the kernel, all the way to tuning gcc > compile options to produce an optimized apache binary, APC for php > caching, etc ..., trust me, its a blazing fast machine for serving PHP > and I hold extreme pride in what I made out of this particular > machine. > > How many clients can this machine serve concurrently? (this machine > does not hold the DB btw, it has only apache) > At 35 requests per second the CPU is at 20% utilization. > At 55 requests per second the CPU is at 40% utilization. > At 75 requests per second the CPU is at 70% utilization. > I was able to squeez 89 RPS at 100% CPU. (and the CPU was the > bottleneck, also bear in mind that the NIC has an onboard processor, > thus networking takes almost nothing from the CPU). > > Want fancy charts with real data? I have attached two charts that show > apache's children state and cpu utilization for the last hour, I can > also provide you with the last 12 months charts that include apache > children stats (busy, idle, waiting...), cpu utilization, memory > utilization, hard disk i/o, all that stuff. > > So for the love of the flying spaghetti monster don't tell me there is > a *single* machine out there serving 2500 PHP and static content > requests per second unless you back up your claim with real numbers. > > Good luck with your cluster and if you need anything else we are here > to help as much as we can :) > > virtually yours > > Zaid > > > > > > On Nov 17, 2007 2:35 PM, Ala'a Ibrahim < [EMAIL PROTECTED]> wrote: > > > > > > > > > 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 > > > --------------------------- > > > > > > > > > > > > > > > > > > > > > > > -- > --------------------------- > 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 -~----------~----~----~----~------~----~------~--~---
