[PHP] Re: [PHP-DEV] PHP scalability problem

[Eddie Drapkin]

Use a FastCGI process manager, then, and you'll have a tighter level of
control.  There's several CPU limiting tools that'll allow you to choke
those processes, or you can simply set their nice value real high so they're
super low priority.  That's more the realm of server configuration than
anything else, though.

On Wed, May 27, 2009 at 12:01 AM, tRace DOliveira wrote:

>
> I think you read me wrong there. I am not looking for speed but trying to
> put less pressure on the server with the work load that it has to do.
> Like makingit do less processing. Kinda like where you have the website
> "bluehost" restricting the amount of processes a person can use. They
> restrict you because of PHP and the processes a person uses, more pressure
> the web server will have.
>
> --- On *Wed, 5/27/09, Eddie Drapkin * wrote:
>
>
> From: Eddie Drapkin 
> Subject: Re: [PHP-DEV] PHP scalability problem
> To: "tRace DOliveira" 
> Date: Wednesday, May 27, 2009, 3:54 AM
>
>
> 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 
> http://us.mc1104.mail.yahoo.com/mc/compose?to=married...@yahoo.com>
> > 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 
>> http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza...@gmail.com>
>> >* wrote:
>>
>>
>> From: Eddie Drapkin 
>> http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza...@gmail.com>
>> >
>> Subject: Re: [PHP-DEV] PHP scalability problem
>> To: "tRace DOliveira" 
>> http://us.mc1104.mail.yahoo.com/mc/compose?to=married...@yahoo.com>
>> >
>> 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 
>> http://us.mc1104.mail.yahoo.com/mc/compose?to=married...@yahoo.com>
>> > wrote:
>>
>>>
>>> What I am trying to get at is that PHP uses processes(Heavy weight) and
>>> 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 
>>> http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza...@gmail.com>
>>> >* wrote:
>>>
>>>
>>> From: Eddie Drapkin 
>>> http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza...@gmail.com>
>>> >
>>> Subject: Re: [PHP-DEV] PHP scalability problem
>>> To: "tRace DOliveira" 
>>> http://us.mc1104.mail.yahoo.com/mc/compose?to=married...@yahoo.com>
>>> >
>>> Cc: "PHP General Mailing List" 
>>> http://us.mc1104.mail.yahoo.com/mc/compose?to=php-gene...@lists.php.net>
>>> >
>>> 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 
>>> http://us.mc1104.mail.yahoo.com/mc/compose?to=married...@yahoo.com>
>>> > 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 
 http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza...@gmail.com>
 >* wrote:


 From: Eddie Drapkin 
 http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza...@gmail.com>
 >
 Subject: Re: [PHP-DEV] PHP scalability problem
 To: "Michael Shadle" 
 http://us.mc1104.mail.yahoo.com/mc/compose?to=mike...@gmail.com>
 >
 Cc: "tRace DOliveira" 
 http://us.mc1104.mail.yahoo.com/mc/compose?to=married...@yahoo.com>>,
 "intern...@lists.php.net"
 http://us.mc1104.mail.yahoo.com/mc/compose?to=intern...@lists.php.net>
 >
 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
 

[PHP] Re: [PHP-DEV] PHP scalability problem

[Eddie Drapkin]

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 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 * wrote:
>
>
> From: Eddie Drapkin 
> Subject: Re: [PHP-DEV] PHP scalability problem
> To: "Michael Shadle" 
> Cc: "tRace DOliveira" , "intern...@lists.php.net" <
> intern...@lists.php.net>
> 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 
> http://us.mc1104.mail.yahoo.com/mc/compose?to=mike...@gmail.com>
> > 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 
>> http://us.mc1104.mail.yahoo.com/mc/compose?to=oorza...@gmail.com>>
>> wrote:
>>
>>  1) PHP is Rarely The Bottleneck:
>>> http://talks.php.net/show/drupal08/
>>>
>>>
>>> 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 
>>> http://us.mc1104.mail.yahoo.com/mc/compose?to=married...@yahoo.com>
>>> >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




>
>

[PHP] Re: [PHP-DEV] PHP scalability problem

[Eddie Drapkin]

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 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 
> Subject: Re: [PHP-DEV] PHP scalability problem
> To: "tRace DOliveira" 
> Cc: intern...@lists.php.net
> Date: Wednesday, May 27, 2009, 2:55 AM
>
>
> 1) PHP is Rarely The Bottleneck: 
> http://talks.php.net/show/drupal08/
> 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 
> http://us.mc1104.mail.yahoo.com/mc/compose?to=married...@yahoo.com>
> > 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
>>
>>
>>
>
>
>
>