Processes are only spawned in shitty webserver processing models that high performing webservers don't even have. If you'll read my first link, php is rarely the client-side bottleneck (which is all that matters). And do some research, on a page that hits the database for me, the query is usually 50-80% of prosecution speed, so design a faster db schema or use a faster RDBMS (or high performing MySQL builds). Offloading processing is rarely possible and is not the solution to scaling your web application, somewhere along the line your server will fail (if you have enough success) and you'll have to get a new one. Scaling gracefully is more about horizontal expansion and getting the most for your buck, delaying the inevitable. Some things you probably ought to keep in mind 1) Client side performance is the only thing that matters. If your server load is at 110 but pages are still generating in less time than it takes to make the HTTP handshake (which I estimate <0.1 seconds is a fair target), then you have no worries. Install ySlow and study its documentation thoroughly and accept no less than high 90s for your work. 2) Scaling requires a fundamental paradigm of speed built in to the core logic of your application. It's easier to start with a persistent caching setup and go from there than apply one later. Look into memcache, memcachedb, and apc for some absolutely required tools. 3) The solution to save your server from doing the majority of the work isn't to load it onto the clients, that'll result in your ownership of a laggy, unresponsive site no one wants to use. I guess that would solve your problem, though, by taking away all your users. 4) Start establishing good performance habits, use a profiler like xdebug and identify your bottlenecks and optimize them. Saving 10ms on a logic setup is meaningless if every pageload has 200ms of queries it has to run. SQL *will* be your benchmark long before PHP or apache will be. Look into setting your SQL server up as fast as you can. Hint: default installs and configurations are never as fast as they could be. 5) Use ajax when you can instead of full page reloads. It saves a lot of overhead i/o if done properly. 6) Install an opcode cache, I recommend EAccelerator. Script CPU time will be decreased by (a) order of magnitude(s). 7) Scalability is a lot of SEO, there's no one magic thing you can do, it's a combination of dozens of tiny little things and it's probably the most difficult thing about writing PHP. Don't expect someone to email this list and say "Do X, Y and Z and you'll never have to worry about scaling!" because they'll be lying to you if that does happen. On a side note, I noticed this is the wrong list and CC'd the correct one. On Tue, May 26, 2009 at 11:04 PM, tRace DOliveira <married_74@xxxxxxxxx>wrote: > > What I am trying to achieve is to have the server do less processing. Like > I said PHP is a server side scripting language and each time a request is > made a process is spawned and processes are heavy weight as compared to a > thread which is a light weight process. So I want to take away much > processing away from the server and have the client do it instead. Because > if many requests are made the server will eventually go down because it will > over the server. > ** > > > From: Eddie Drapkin <oorza2k5@xxxxxxxxx> > Subject: Re: [PHP-DEV] PHP scalability problem > To: "tRace DOliveira" <married_74@xxxxxxxxx> > Cc: internals@xxxxxxxxxxxxx > Date: Wednesday, May 27, 2009, 2:55 AM > > > 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 >> >> >> > > > >
