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 is Rarely The Bottleneck:
http://talks.php.net/show/drupal08/http://talks.php.net/show/drupal08/7 - Invest in an opcode cache
- DB I/O is always the most restrictive part of your application, read the
mysql performance blog (a lot applies for postgres too) - If you're serious about scalability, ditch apache and use a better
webserver - You're describing what ajax does in a lot of cases
- Have you deployed flatfile cache / apc / memcached? If so, how?
- Do you regularly run siege tests on new server stacks and profile each
piece's impact on performance? - 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@yahoo.comwrote:
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
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.
- PHP is Rarely The Bottleneck:
http://talks.php.net/show/drupal08/<http://talks.php.net/show/drupal08/7
- Invest in an opcode cache
- DB I/O is always the most restrictive part of your application,
read the
mysql performance blog (a lot applies for postgres too)- If you're serious about scalability, ditch apache and use a better
webserver- You're describing what ajax does in a lot of cases
- Have you deployed flatfile cache / apc / memcached? If so, how?
- Do you regularly run siege tests on new server stacks and profile
each
piece's impact on performance?- 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@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
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)
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.
- PHP is Rarely The Bottleneck:
http://talks.php.net/show/drupal08/http://talks.php.net/show/drupal08/7
- Invest in an opcode cache
- DB I/O is always the most restrictive part of your application, read
the
mysql performance blog (a lot applies for postgres too)- If you're serious about scalability, ditch apache and use a better
webserver- You're describing what ajax does in a lot of cases
- Have you deployed flatfile cache / apc / memcached? If so, how?
- Do you regularly run siege tests on new server stacks and profile each
piece's impact on performance?- 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@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