Re: PHP causing high number of NFS getattr operations?

From: Date: Fri, 22 Feb 2013 10:56:02 +0000
Subject: Re: PHP causing high number of NFS getattr operations?
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
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

Thread (33 messages)

« previous php.internals (#66153) next »