Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115938 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 43133 invoked from network); 3 Sep 2021 16:33:39 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Sep 2021 16:33:39 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7DF021804B4 for ; Fri, 3 Sep 2021 10:10:09 -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.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) (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 10:10:09 -0700 (PDT) Received: by mail-pj1-f50.google.com with SMTP id mj9-20020a17090b368900b001965618d019so6603pjb.4 for ; Fri, 03 Sep 2021 10:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lyda.ie; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a2hUy5n3gSFuk/9G+zUaABO9ywgWvZ7XVF9Fx6tB6+U=; b=X5jWsveYluoaCyr5d9z3K8vtXfVJpOMImsYQGw27RuVAXAtRGqXXE/ZK9lxuHRL13s bxO7/rq9M5ZncoKOE/0kr8LTYg/W8gRUZdlGADZtVnFCODqkXLIgtTEY0EfwGGTcfvZI RZ0y60p9wgkVAJaRAaMikgVdlbDCJOBVAvwOqHAAtzJkQ45hFYmFZS9Xnhg0LUpmdAZd nSBJudISI3E703KgsTdlMZIhQgxB8rtsVhmIpJLO2grQUMHbB65XT0u5ZQcst7+6yRyN EOYf7uC5NxNUg+ViNDymJkmfgsIgRMda5mwsn4Q1Hv0irLga+jkhJ8OHvpdmvPtqDCrs 6Law== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a2hUy5n3gSFuk/9G+zUaABO9ywgWvZ7XVF9Fx6tB6+U=; b=S5sj4KR16MannXxPbmnZ95EYYMezYA1cSgKcmIKJLfj7jNxBdGJ4nkH5SvfTW7Gg+f XkNe7a4ADLZ4HxKvwR9zm5dpITtmzzJUdycjFPdwi1JQ+M6xEhbUp33xWV7BbP3IG5zS ENKoE7Ib7OgygH3ODXuhyoTmmQuQR8+Y7hWC0DpcFxA5hQLfWvSr05INQpzMw5iX8qny UJmkYwlJGVx/LpZvCpJfvHWQ5bEQ/ZTupe+2q+BpJk3wDkgCAf9IRwlf88IBIOyUxppF GGk5sIUi/G9Ikon6uKj0PegMW1u1LtkC2d53xSqRjIJlmfUnnf+c6NMa/u5+pEEs5LeD uLTQ== X-Gm-Message-State: AOAM531NZkRLB7V6FVk+jiyPEEMgOVFNfIfOazQL4Ij7v/Q4BS29kHK+ HUuVvYMKqAXDivG5Qf5Icn4uKLWYTuEZOuZQwre0LA== X-Google-Smtp-Source: ABdhPJzg4zdqdAG/wk4xKAwircnJWaAj8F+G7qOFIZwudGf1xCXDggvXpXCy02WQXz+n/czv6h41eaVmoqMJBT9CkTo= X-Received: by 2002:a17:902:c613:b0:136:5fc8:5372 with SMTP id r19-20020a170902c61300b001365fc85372mr3841353plr.41.1630689006855; Fri, 03 Sep 2021 10:10:06 -0700 (PDT) MIME-Version: 1.0 References: <0A048A30-444F-4DB0-A79C-9EA9BD07B1EC@cschneid.com> <569E3A48-E3F5-46FA-BA08-D2493CE4FD33@cschneid.com> In-Reply-To: <569E3A48-E3F5-46FA-BA08-D2493CE4FD33@cschneid.com> Date: Fri, 3 Sep 2021 18:09:55 +0100 Message-ID: To: Christian Schneider Cc: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] Adding a way to disable the stat cache From: kevin@lyda.ie (Kevin Lyda) [sent a second time, now to the list, sorry] On Fri, Sep 3, 2021 at 3:53 PM Christian Schneider wrote: > 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. Using this bash script: #!/bin/bash echo "Without cache" time ./sapi/cli/php -d enable_stat_cache=3DFalse "$@" echo "With cache" time ./sapi/cli/php "$@" To run this php script: 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-file-notes > clearly states that is_file() is cached and clearstatcache() should be used. That may be, but it happens for people. > Yes, the stat cache is a foot gun, but it was put in for a reason back in the day. Well, we each have opinions on the validity of those reasons. May they bring us joy. > 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 regressio= n. I was asking for data backing up the claim that this regression either d= oes 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. OK, but as you note, not what this PR is going to do. > b) Making it an .ini-Option seems to be a BC preserving measure but, in f= act, 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 possib= le, see magic_quotes :-) First, it's possible to disable other caches in PHP. In fact, I think this is the only cache you can't disable. So it puts it in line with all other caches. Second, it's not possible to make this cache work correctly. But hey, it's hardly the only cache with that problem. There are several ini-cache settings that will make code behave differently. Pretty much every cache setting for example. Kevin