Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44076
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.166 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=references:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:x-mailer:mime-version:subject:date:cc;
        b=GbJo8hYjXaP9rO4XVPoh1aZgME2uBFneUzUhKZojzilnr3GPs7v+apgsJjStUhQh2Y
         Pk8UuycwAbNP0glXuqqmMbLWFEouESC4IYcY23ch7GcYm2MN31kq9LbVo69nCKmoNdqn
         DhDf1KffWzDfzLmDQ35JghUNulQrnf2By2+iY=
References: <826683.74097.qm@web110405.mail.gq1.yahoo.com> <68de37340905261955r51175134n4a1c6881cd3a76b9@mail.gmail.com>
Message-ID: <112D4725-3254-4C77-97CA-9A6A0D81B043@gmail.com>
To: Eddie Drapkin <oorza2k5@gmail.com>
In-Reply-To: <68de37340905261955r51175134n4a1c6881cd3a76b9@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 5H11)
Date: Tue, 26 May 2009 20:24:52 -0700
Cc: tRace DOliveira <married_74@yahoo.com>,
 "internals@lists.php.net" <internals@lists.php.net>
Subject: Re: [PHP-DEV] PHP scalability problem
From: mike503@gmail.com (Michael Shadle)

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@gmail.com> 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@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
>>
>>
>>