[sent a second time, now to the list, sorry]
On Fri, Sep 3, 2021 at 3:53 PM Christian Schneider
<cschn...@cschneid.com> 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:
<?php
$iterations =3D 1000000;
function all_the_stats($filename) {
@lstat($filename);
@stat($filename);
}
while ($iterations--) {
all_the_stats(__FILE__);
}
I see this output:
Without cache
real 0m7.326s
user 0m5.877s
sys 0m1.448s
With cache
real 0m5.010s
user 0m5.009s
sys 0m0.000s
So that's 2 seconds slower to do 2 million uncached stat calls vs
cached with a 100% cache hit rate (minus the first stat/lstat calls).
Technically, yes, it's slower, but I'd suggest that making 2 million stat
calls to a single file is a bad idea. And remember, the cache holds *one*
file. If you stat a second file it's a cache miss.
> 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
> <https://www.php.net/manual/en/function.is-file.php>
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
