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>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>* wrote: > > > From: Eddie Drapkin <oorza2k5@xxxxxxxxx> > Subject: Re: [PHP-DEV] PHP scalability problem > To: "Michael Shadle" <mike503@xxxxxxxxx> > Cc: "tRace DOliveira" <married_74@xxxxxxxxx>, "internals@xxxxxxxxxxxxx" < > 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 >>>> >>>> >>>> >>>> > >
