If you think that's a problem, then yes. Look into nginx. But honestly, you're not going to notice a speed improvement at all (maybe if you were serving 2000 loads/sec you would, but only then if it's on a small box). On Tue, May 26, 2009 at 11:52 PM, tRace DOliveira <married_74@xxxxxxxxx>wrote: > I also thought that it's PHP that causes the processes. Thanks that helps > me alot. So the problem is not with the language itself but the web > server(Apache)? > > --- On *Wed, 5/27/09, Eddie Drapkin <oorza2k5@xxxxxxxxx>* wrote: > > > From: Eddie Drapkin <oorza2k5@xxxxxxxxx> > Subject: Re: [PHP-DEV] PHP scalability problem > To: "tRace DOliveira" <married_74@xxxxxxxxx> > Date: Wednesday, May 27, 2009, 3:47 AM > > > ... no > > Apache uses processes, but can also use threads. nginx and lighttpd both > use a threaded model. But you seem to have this idea in your head that it's > PHP's fault and switching to a threaded webserver / CGI model will solve any > noticeable scalability problems, so feel free to ditch PHP for ASP because > you think it'll be anywhat faster. I'll save you some time: it won't. > > On Tue, May 26, 2009 at 11:44 PM, tRace DOliveira <married_74@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=married_74@xxxxxxxxx> > > wrote: > >> >> What I am trying to get at is that PHP uses processes(Heavy weight) and >> ASP.NET <http://asp.net/> uses threads which are light weight. So it >> inflicts less strain upon the web server. So I am trying to solve the >> problem of the strain that PHP causes on ther server. >> --- On *Wed, 5/27/09, Eddie Drapkin <oorza2k5@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza2k5@xxxxxxxxx> >> >* wrote: >> >> >> From: Eddie Drapkin <oorza2k5@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza2k5@xxxxxxxxx> >> > >> Subject: Re: [PHP-DEV] PHP scalability problem >> To: "tRace DOliveira" <married_74@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=married_74@xxxxxxxxx> >> > >> Cc: "PHP General Mailing List" <php-general@xxxxxxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=php-general@xxxxxxxxxxxxx> >> > >> Date: Wednesday, May 27, 2009, 3:39 AM >> >> >> >> I seriously doubt it. PHP is a better language in almost all regards and >> is much much more popular. A lot of people make that decision every day and >> I'd say most of them choose PHP. Why ask that, though? >> >> On Tue, May 26, 2009 at 11:36 PM, tRace DOliveira <married_74@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=married_74@xxxxxxxxx> >> > wrote: >> >>> >>> Do you agree with me that when building a large web application that >>> people would rather choose ASP.Net over PHP if people had to choose between >>> those two ? >>> --- On *Wed, 5/27/09, Eddie Drapkin <oorza2k5@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza2k5@xxxxxxxxx> >>> >* wrote: >>> >>> >>> From: Eddie Drapkin <oorza2k5@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza2k5@xxxxxxxxx> >>> > >>> Subject: Re: [PHP-DEV] PHP scalability problem >>> To: "Michael Shadle" <mike503@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=mike503@xxxxxxxxx> >>> > >>> Cc: "tRace DOliveira" <married_74@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=married_74@xxxxxxxxx>>, >>> "internals@xxxxxxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=internals@xxxxxxxxxxxxx>" >>> <internals@xxxxxxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=internals@xxxxxxxxxxxxx> >>> > >>> Date: Wednesday, May 27, 2009, 3:29 AM >>> >>> >>> nginx and php-fpm is the fastest setup I could find, after spending >>> almost 2 weeks trying different combinations. >>> >>> Apache pre-fork model: 1900 reqs/second (this is with running queries per >>> pageload) >>> nginx w/ fpm: 3400 reqs/second >>> >>> And nginx's doc setup is awesome. >>> >>> Like Michael said, scaling PHP itself is no big deal, just add more >>> worker nodes to your process pool, the issue is scaling out your sql server >>> (memcache scaling is piss easy too) >>> >>> On Tue, May 26, 2009 at 11:24 PM, Michael Shadle <mike503@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=mike503@xxxxxxxxx> >>> > wrote: >>> >>>> Succinct and great reply. >>>> >>>> Better webserver: nginx :) >>>> >>>> #3 is probably the most important piece. >>>> >>>> I'd like to also note scaling php is pretty simple. Scaling out >>>> typically provides better results as opposed to scaling up. Scaling your >>>> datastore will always be your pain point. Adding new data nodes is complex. >>>> Adding more php processing nodes is simple. Php nodes are just worker bees. >>>> They're great for shared-nothing processing engines. >>>> >>>> I can't think of a good metaphor right now other than that. >>>> >>>> On May 26, 2009, at 7:55 PM, Eddie Drapkin <oorza2k5@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza2k5@xxxxxxxxx>> >>>> wrote: >>>> >>>> 1) PHP is Rarely The Bottleneck: >>>>> http://talks.php.net/show/drupal08/< >>>>> http://talks.php.net/show/drupal08/7> >>>>> >>>>> 2) Invest in an opcode cache >>>>> 3) DB I/O is always the most restrictive part of your application, read >>>>> the >>>>> mysql performance blog (a lot applies for postgres too) >>>>> 4) If you're serious about scalability, ditch apache and use a better >>>>> webserver >>>>> 5) You're describing what ajax does in a lot of cases >>>>> 6) Have you deployed flatfile cache / apc / memcached? If so, how? >>>>> 7) Do you regularly run siege tests on new server stacks and profile >>>>> each >>>>> piece's impact on performance? >>>>> 8) Do you profile your code every time you change some piece of logic? >>>>> >>>>> Scalability is an enormous mountain to climb and there's only so much >>>>> you >>>>> can offload on to the client. Chances are there's more room for >>>>> improvement >>>>> at any stage in your development than there is potentiality for >>>>> client-side >>>>> processing. >>>>> >>>>> On Tue, May 26, 2009 at 10:46 PM, tRace DOliveira < >>>>> married_74@xxxxxxxxx<http://us.mc1104.mail.yahoo.com/mc/compose?to=married_74@xxxxxxxxx> >>>>> >wrote: >>>>> >>>>> PHP is a server side scripting language, so that means that the server >>>>>> will >>>>>> have to do the bulk of the processing if not most. >>>>>> I was thinking about shifting the processing to the client. Kinda like >>>>>> how >>>>>> java does it. I don't know really know how java does it but it would >>>>>> be >>>>>> interesting if it could be done for PHP also. >>>>>> Thank you, >>>>>> Leonard D'Oliveira >>>>>> >>>>>> >>>>>> >>>>>> >>> >>> >> >> > >
