Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66153
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ellisons.org.uk from 79.170.44.47 cause and error)
Message-ID: <51274EC2.7090108@ellisons.org.uk>
Date: Fri, 22 Feb 2013 10:56:02 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Brendon Colby <brendon@newgrounds.com>, 
 Daniel Zoltak <daniel@zoltak.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAHHbRnEUVcGqH6+++CWXM6XWobJn5MzKxLdfX9RHxoJ0uXaZdg@mail.gmail.com> <51229088.90306@lerdorf.com> <5122DA51.6090606@sugarcrm.com> <5122DBA9.2010004@lerdorf.com> <5122E00F.80409@sugarcrm.com> <5122E451.1040308@lerdorf.com> <CAHHbRnEZo9nmon+yhvnEW0t2FFV_veBXzkSdDjDXEvpfet141A@mail.gmail.com> <5126B009.4090203@lerdorf.com> <5126BE9D.2060507@ellisons.org.uk> <5126C267.2000806@lerdorf.com>
In-Reply-To: <5126C267.2000806@lerdorf.com>
Content-Type: multipart/alternative;
 boundary="------------090804020203060009080403"
Subject: Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
From: Terry@ellisons.org.uk (Terry Ellison)

--------------090804020203060009080403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ramus, thanks for your detailed response.
>>>> NFS is so common for sharing files that ...
>>> This is simply not true. I do have a fair bit of experience in this
>>> field, and I don't know of any major sites that do this and I have
>>> worked with a good chunk of the largest sites out there.
>> Eh???  Fortune 500 enterprises and governmental departments are pretty
>> conservative.  NAS and SAN based iSCSI and FCoE based elastic block
>> storage give great performance for server-specific file-systems, but
>> Brendon is right: for distributed file systems, NFS and CIFS still
>> dominate.
> By major I meant traffic-wise, not Fortune-500, although there are some
> of those on the list too. I mostly work with medium-to-large scale
> Internet companies. Think Yahoo, Facebook, Flickr, Digg, Etsy, WePay,
> Room77. These types of companies would never consider serving all their
> Web traffic from NFS. Yes, Yahoo had a ton of Netapp filers as well, but
> this was for shared data storage, they would never consider putting
> their application logic on them.
Now I agree with you: for this sector of Internet B2C companies, their 
business is centred around a small number of apps that dominate their 
revenue streams, so of course they are free to design their 
infrastructure architecture to optimize the performance of these apps. I 
also accept that this sector was and is directly or indirectly the major 
funder of PHP development effort.

However, my counter point is that this is no longer the only 
infrastructure usecase for PHP.  Now mature, it has entered other 
sectors and Brendon and Daniel posts highlight two of them:

  * Enterprise use as Brendon raises.  Enterprises have moved to use
    internet based technologies to automate internal business
    processes.  These apps work on the company intranet, not on the
    internet. So when you book a car or go to your bank or order a part
    from a manufacturer, the assistant may well be sitting in front of a
    PHP app that never sees the internet but is still core to that
    business.  Thanks partly to the flexibility of cloud resources, CIOs
    and CTOs are increasingly looking at open technologies such PHP to
    replace MS ones.  Incidentally IMO, its this sort of business stream
    that will provide hard funding to value-add companies such as Zend.

  * The hosting service providers as Daniel raises.  In terms of sheer
    numbers this is that largest community of PHP users who buy their
    +/- $100pa service from a hosting provider.  They still care about
    performance.  The providers care about the efficiency of their
    infrastructure.  They (initially) using PHP because Wordpress,
    Mediawiki, ... are written in it. But this is also a major entry
    vehicle for a new generation of PHP developers to get an initial
    internet presence.  If PHP runs 3x slower than language X, and X is
    just as flexible then we are putting up unnecessary barriers to
    their entry and turning away that new cadre.

> This is also something that has been like this for 10+ years and nobody
> has stepped up to fix it so far. It shouldn't be news to anyone that
> stats and opens over NFS are slow. I am not sure why it should suddenly
> be an urgent problem for us at this point. But like I said, we may get
> to it.
It's not suddenly urgent but perhaps this is more a question of maybe 
hitting a tipping point where it might now be wise to address this issue.
>   If the integrated opcode cache happens it becomes easier to
> manage the flow between the compiler, the cache and the executor and we
> can probably optimize some things there.
+1
> And as I mentioned in another thread, let's see some RFCs proposing how
> to fix some of these things rather than simply posting "I wish the PHP
> devs would do this.." type of messages. These go over really badly with
> most of the longtime contributors here and they even tend to have the
> opposite of the desired effect.
As I have posted separately, I forked and then rewrote APC to address 
this sweet spot.  OK my LPC is very a much bug-ridden alpha code that 
fails 10% of the PHP test suite largely due to extension 
interoperability issues, and I've had other things to do this last month 
-- including deciding whether to switch to a proper O+ delta. However, 
my aim was for me to use this as an evaluation test bed, not a serious 
production contender.  However, now that I've written an opcode cache 
which runs Mediawiki under php-cgi (with ~ 5% of the NFS getattrs, BTW), 
rolling some key tweeks into the Zend compiler, execution environment 
and APC -- which I understand well and should be straight forward -- or 
O+ -- which I don't as yet.

My challenge is deciding (i) do I work on PHP 5.6 / 5.7 and the 
corresponding beta APC version which at current rates of adoption might 
have begin to have an impact in the community sometime in the next 5 
years, or (ii) work on a performance patch to the stable APC version 
which is typically installed with PHP 5.3 which these guys could apply 
within a few months.

I'll draft the RFCs if the webmaster gives me the karma to do so.

Regards Terry

--------------090804020203060009080403--