Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115932 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 28687 invoked from network); 3 Sep 2021 14:16:22 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Sep 2021 14:16:22 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A1A671804C9 for ; Fri, 3 Sep 2021 07:52:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS1836 195.49.0.0/17 X-Spam-Virus: No X-Envelope-From: Received: from darkcity.gna.ch (darkcity.gna.ch [195.49.47.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 3 Sep 2021 07:52:51 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:1205:502d:fa80:5cf1:8b5b:a823:3c77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 80F6F151668F for ; Fri, 3 Sep 2021 16:52:49 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5270BACD-197D-43AB-8F6D-4D3255771230" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 3 Sep 2021 16:52:49 +0200 References: <0A048A30-444F-4DB0-A79C-9EA9BD07B1EC@cschneid.com> To: PHP internals In-Reply-To: Message-ID: X-Mailer: Apple Mail (2.3654.120.0.1.13) Subject: Re: [PHP-DEV] Adding a way to disable the stat cache From: cschneid@cschneid.com (Christian Schneider) --Apple-Mail=_5270BACD-197D-43AB-8F6D-4D3255771230 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 03.09.2021 um 16:07 schrieb Kevin Lyda : > On Fri, Sep 3, 2021 at 2:34 PM Christian Schneider > wrote: >> If I remember correctly it was about reducing the number of system = calls. Is this no issue any more? >> Has a quick benchmark been done to see the positive / negative impact = of the stat cache for a typical application? >=20 > In the lifespan of php it really wasn't an issue unless someone was > doing something that wasn't wise - I can't think of a single reason to > stat a file in a tight loop. How can you say "it never was a problem" if we never had to live without = stat cache? Can you back up that claim with numbers? There are some of us who run = high-volume websites where system load increase could be a problem. > However more importantly the current behaviour returns bad data for > perfectly correct programs. So for example on a unix box... >=20 > passthru('touch foo'); > if (is_file('foo')) { > echo "Correct\n"; > } > passthru('rm foo'); > if (is_file('foo')) { > echo "Incorrect\n"; > } > ?> I disagree that this (with current PHP) is a correct program. The = documentation at = https://www.php.net/manual/en/function.is-file.php#refsect1-function.is-fi= le-notes clearly states that is_file() is cached and clearstatcache() should be = used. Yes, the stat cache is a foot gun, but it was put in for a reason back = in the day. > Personally I value correctness first and then performance is a > priority further down that list of attributes (security and > readability would also be higher priorities). However as the current > behaviour has existed for several decades, this change makes sure the > incorrect historical behaviour is the default. There are two problems here: a) Removing the stat cache altogether (which is not your proposal, I = know, but it was mentioned in the thread) could lead to a performance = regression. I was asking for data backing up the claim that this = regression either does not exist or is small enough to not be a problem. = Just saying "it never was a problem" or "modern Linux should handle = this" does not give me that certainty. b) Making it an .ini-Option seems to be a BC preserving measure but, in = fact, it creates an even bigger issue: Your code snippet is correct or = buggy depending on an ini-settings. Something we want to avoid as much = as possible, see magic_quotes :-) - Chris --Apple-Mail=_5270BACD-197D-43AB-8F6D-4D3255771230--