Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66082 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15486 invoked from network); 20 Feb 2013 23:52:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Feb 2013 23:52:28 -0000 Authentication-Results: pb1.pair.com header.from=brendon@newgrounds.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=brendon@newgrounds.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain newgrounds.com designates 209.85.214.50 as permitted sender) X-PHP-List-Original-Sender: brendon@newgrounds.com X-Host-Fingerprint: 209.85.214.50 mail-bk0-f50.google.com Received: from [209.85.214.50] ([209.85.214.50:52215] helo=mail-bk0-f50.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A1/12-03224-AB165215 for ; Wed, 20 Feb 2013 18:52:28 -0500 Received: by mail-bk0-f50.google.com with SMTP id jg9so3839538bkc.9 for ; Wed, 20 Feb 2013 15:52:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=6KXM/q4HK4PWxFF7O5UGuFxD5kurHxgOEOE19BTQ6f0=; b=cNF7m+4Ql7n1yBXZFDhFi/CzJhicIU9QTFV392bEhpyaeaf/lFhI/0kwfJBrnZ2nY+ AKSjX8VI32lE2F6/MuDDQS5+dHcWjEB8+HsA8XA5+lKy6EGpePkwWL8ciBzGzFsYpYwk P2XcrQ5PV1hwD6U4KXVRudz8p5xIi5G1qNOi/XQ4EPakHgsOnRaB2j3UcA9uRhKG8ZxE Jri12Bcuus6CV+Gh1OEVcMyHleTR+QHd9wt1plCUus4iMvCu/XOWiKjg/I1u2yzXyKMF rxdb8SJ+ItTberf8u/M3MCrWGHLCac94/SPq5jbRzQeTV32cFVOBrHd2Cx12qNc1dTBP z4vg== MIME-Version: 1.0 X-Received: by 10.204.8.15 with SMTP id f15mr9578050bkf.88.1361404343150; Wed, 20 Feb 2013 15:52:23 -0800 (PST) Received: by 10.204.27.19 with HTTP; Wed, 20 Feb 2013 15:52:22 -0800 (PST) In-Reply-To: <5123A2FE.1050101@ellisons.org.uk> References: <51229088.90306@lerdorf.com> <5122DA51.6090606@sugarcrm.com> <5122DBA9.2010004@lerdorf.com> <5122E00F.80409@sugarcrm.com> <5122E451.1040308@lerdorf.com> <51234789.4030405@ellisons.org.uk> <5123A2FE.1050101@ellisons.org.uk> Date: Wed, 20 Feb 2013 18:52:22 -0500 Message-ID: To: Terry Ellison Cc: "internals@lists.php.net" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlvziGHO0fA3AcDmThtu3gpjc9nxYkrtqPhZb7ioU9VWy3Axoh9kuWgggl3+jo1snTwQmGV Subject: Re: [PHP-DEV] PHP causing high number of NFS getattr operations? From: brendon@newgrounds.com (Brendon Colby) On Tue, Feb 19, 2013 at 11:06 AM, Terry Ellison wrote: > Brendon, > > Just to follow up with a bit more detail, apart from the obvious NFS tuning > with things like the actimeo mount parameters, you can get a better idea of > what is going on if you use a local copy of one of your apps running under a > local linux apache server. This is an example from my Ubuntu laptop, but it > works just as well on a test VM if you still use WinXX on your PC. > > trace_wget () { > sleep 1 > coproc sudo strace -p $(ps -C apache2 --no-headers -o pid) -tt -o > /tmp/strace$1.log > sleep 1; ST_PID=$(ps -C strace --no-headers -o pid) > wget "http://localhost/$2" -O /dev/null -o /dev/null > sleep 2; sudo kill $ST_PID > } > # start Apache in debug mode > sudo service apache2 stop > sudo bash -c ". /etc/apache2/envvars; coproc apache2 -X" > > # trace three gets > trace_wget 0 phpinfo.php > trace_wget 1 mwiki/index.php?title=Main_Page > trace_wget 2 mwiki/index.php?title=Main_Page > > #restart normally > sudo service apache2 stop > sudo service apache2 start > sudo chmod 777 /tmp/strace?.log > > grep -c "open(" /tmp/strace?.log > grep -c "stat(" /tmp/strace?.log > > The first get is just to load and prime the mod_php5 thread (Ubuntu has a > crazy localtime implementation), the second loads and compiles the PHP > MediaWiki modules needed to render a page, the third repeats this now fully > cached in ACP. In this case, > we have: > > open() fstat()/lstat() > /tmp/strace1.log 108 650 (Priming the APC cache) > /tmp/strace2.log 27 209 (Using the APC cache) > > So APC *does* materially reduce the I/O calls, and (if you look at the > traces) it removes most of the mmaps and compilation. The MWiki autoloader > uses require() to load classes but in the code as a whole the most common > method of loading modules is require_once() (414 uses as opposed to 44 in > total of the other include or require functions) and as I said in my > previous post, this I/O is avoidable by recoding the ZEND_INCLUDE_OR_EVAL > hander to work cooperatively with the opcode cache when present. > > Note that even when the cache does this, it still can't optimize coding > patterns like: > > if ( file_exists( "$IP/AdminSettings.php" ) ) { > require( "$IP/AdminSettings.php" ); > } > > and IIRC mwiki does 4 of these on a page render. Here a pattern based on > (@include($file) == 1) is more cache-friendly. > > Now this isn't a material performance issue when the code tree is mounted on > local storage (as is invariably the case for a developer test configuration) > as the stat / open overhead of a pre-(file) cached file is microseconds, but > it is material on scalable production infrastructure which uses network > attached NFS or NTFS file systems. > > So in summary, this is largely avoidable but unfortunately I don't think > that we can persuade the dev team to address this issue, even if I gave them > the solution as a patch :-( > > Regards > Terry Ellison Terry, Thanks for your detailed input. This is essentially what I did in my test setup. APC is definitely critical to the performance of our site. I'm just very curious to see how much impact the high number of getattr operations coming from the Apache/PHP servers is having on the filer. It looks like we might be able to move our PHP files to local storage to at least measure the impact this is having. Brendon