Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65922 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84526 invoked from network); 19 Feb 2013 02:32:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Feb 2013 02:32:55 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.210.51 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.210.51 mail-da0-f51.google.com Received: from [209.85.210.51] ([209.85.210.51:64397] helo=mail-da0-f51.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6F/09-34654-654E2215 for ; Mon, 18 Feb 2013 21:32:55 -0500 Received: by mail-da0-f51.google.com with SMTP id n15so2727184dad.24 for ; Mon, 18 Feb 2013 18:32:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=kSEsMS5qvaqSQXP6c4eEf6Y8a5J0FSWvXWoN9DBs0yE=; b=cC4X0wjSfCiWK6Iaq7C2Dd8cj2axsdeKm9PknE7QcoyBqWtjPMLD+GGsWz4K1++P4n PzyPOtKoBfxUKzqnHiVmHG6Fw+TGdXI0+QRiKmRbu7WCZ8cFudw+ta07ReZu2oO9vC/t QxigPNu+05OvaB3FADeX/MsF5OaCHJCKMrLnp8pPZRdetl7+unaP+3k9yLezWIA0rXW3 4C19BW+IWQPa9usp1pl2k7en2VJ6hYT6Hj4oYQAHDQ5gl6DXolgP0m05dQ3fKlDQBtjH HprSR8JQgdut1c9gPySFJoNGTm3LNOYmnKa9GcDKDYKgXSkblPnZrr2xADx2fk4LgoNz znRg== X-Received: by 10.66.2.132 with SMTP id 4mr41431464pau.11.1361241171534; Mon, 18 Feb 2013 18:32:51 -0800 (PST) Received: from [192.168.200.148] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPS id rn14sm16264779pbb.33.2013.02.18.18.32.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 18:32:50 -0800 (PST) Message-ID: <5122E451.1040308@lerdorf.com> Date: Mon, 18 Feb 2013 18:32:49 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Stas Malyshev CC: "internals@lists.php.net" References: <51229088.90306@lerdorf.com> <5122DA51.6090606@sugarcrm.com> <5122DBA9.2010004@lerdorf.com> <5122E00F.80409@sugarcrm.com> In-Reply-To: <5122E00F.80409@sugarcrm.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkFWVhnUAm8F/vN2dq5NFd36KKyKt/7z6xjJXPlEIxmwZvPPCqcUobgzwgATQ10sgqLc0gl Subject: Re: [PHP-DEV] PHP causing high number of NFS getattr operations? From: rasmus@lerdorf.com (Rasmus Lerdorf) On 02/18/2013 06:14 PM, Stas Malyshev wrote: > Hi! > >> Yeah, but NFS, especially without the realpath cache, which you lose if >> you turn on open_basedir, is deathly slow because of all the stats. >> >> Typically PHP scripts are not actually "writable files" and the way to >> keep them in synch across multiple machines is to use a deploy >> mechanism/rsynch to deploy them. You may very well have some writable > > rsync may be way too slow if you need the change appear more or less > "immediately" on all servers. Unless you run rsync each second if which > case you're probably better off with NFS :) > >> files that need to be shared at the app-level, but then we wouldn't be >> talking about PHP stat calls and the realpath cache. And most people > > You would still if the data is stored as php file. Which last time I > tested - given APC or something like - was the fastest way to get a > bunch of data into PHP (it was faster than loading and unserializing, > even with APC/memcache). > >> have moved to something like memcache for sharing writable data across >> machines. > > memcache is non-persistent. It's a cache, not a storage solution, so you > can not use it for anything that actually needs to be stored permanently. Sure, but then you can go with something like Redis. But, again, if you go back to the original question, this has nothing to do with often-changing data in a couple of PHP include files: We have several Apache 2.2 / PHP 5.4 / APC 3.1.13 servers all serving mostly PHP over NFS (we have separate servers for static content)." So they are serving up all their PHP over NFS for some reason. -Rasmus