Re: [PHP-DEV] Adding a way to disable the stat cache

[Pierre Joye]

Good morning,

On Sat, Sep 4, 2021 at 4:51 AM Hans Henrik Bergan  wrote:
>
> PS i've seen *HORRIBLE* fs performance for php-running-on-windows,
> where the same filesystem operations on the same files took like 5 seconds
> on linux-running-on-vmware-on-laptop-running-windows-10, versus several
> minutes for the same operation on the same laptop on windows 10 directly..
> for people looking for best-case-scenario for the stat cache, try looking
> at windows fs performance.. (if anyone even cares about that? i personally
> don't, i never run anything performance-sensitive-php code on Windows, just
> noticed horrible fs performance in the past)

Windows TS is as far as I remember the main reason for stat cache
being there as well. Not necessarily because stats are slower on
windows but because a userland stat causes multiple system stat
(virtual cwd and related does multiple calls ). It was and most likely
still is a performance hit back then.

As for the option to disable stat cache, I don't see how it can hurt,
as long as it is well documented and off by default. So daemon and
similar apps can disable it if desired. Other apps, I honestly do not
see any gain :).

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Adding a way to disable the stat cache

[Hans Henrik Bergan]

PS i've seen *HORRIBLE* fs performance for php-running-on-windows,
where the same filesystem operations on the same files took like 5 seconds
on linux-running-on-vmware-on-laptop-running-windows-10, versus several
minutes for the same operation on the same laptop on windows 10 directly..
for people looking for best-case-scenario for the stat cache, try looking
at windows fs performance.. (if anyone even cares about that? i personally
don't, i never run anything performance-sensitive-php code on Windows, just
noticed horrible fs performance in the past)

On Fri, 3 Sept 2021 at 22:22, Kevin Lyda  wrote:

> On Fri, Sep 3, 2021 at 9:12 PM Christian Schneider
>  wrote:
> > I'm interested in the load put on a system with a high request count and
> a typical application.
> > Reducing system calls used to matter there as the kernel does not
> multi-process the same way user land does.
> >
> > But then again, maybe I'm overly cautious :-)
>
> This PR allows people to do just that experiment.
>
> Kevin
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Adding a way to disable the stat cache

[Kevin Lyda]

On Fri, Sep 3, 2021 at 9:12 PM Christian Schneider
 wrote:
> I'm interested in the load put on a system with a high request count and a 
> typical application.
> Reducing system calls used to matter there as the kernel does not 
> multi-process the same way user land does.
>
> But then again, maybe I'm overly cautious :-)

This PR allows people to do just that experiment.

Kevin

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 03.09.2021 um 18:12 schrieb Kevin Lyda mailto:ke...@lyda.ie>>:
> To run this php script:
> 
>  $iterations = 100;
> 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 this is almost a 50% performance regression ;-)
And the more interesting number for me here is "sys 0m1.448s" vs "sys 
0m0.000s". Which means 1.5s out of the additional 2.3s are spent in system 
calls.
Side-note: Why is the user time without cache higher than with cache? That 
seems counter-intuitive. Maybe the checking of the ini-settings or some 
libc-code?

I'm interested in the load put on a system with a high request count and a 
typical application.
Reducing system calls used to matter there as the kernel does not multi-process 
the same way user land does.

But then again, maybe I'm overly cautious :-)

Regards,
- Chris

Re: [PHP-DEV] [RFC] Random Extension 3.0

[Go Kudo]

Thanks nikita.

> ext/standard to ext/random. Why does it do this?

There are several reasons for this.

- The `random` extension name is already used by ext/standard and may
interfere with the build system.
- Due to the namespace rules for new extensions, it is inappropriate to
rename an extension.
- Due to history, the rand / mt_rand dependency is tricky and I thought it
was time to sort it out.
- I don't think it's a good idea to have multiple header files for a single
domain feature.
- As stated in the Future Scope, I wanted to be in a position to eliminate
module global random number state in the future.
- The existing implementation and the object implementation share most of
the same logic. It was necessary to merge them into one to make them common.

I certainly didn't want to require a workaround for PHP 8.2 or later for
extensions that depended on ext/standard respectively, but I decided that I
had no choice for the above reasons.

> just don't make it a requirement.

I would like to modify the design.

> I don't think it makes sense to switch these functions to use
cryptographic randomness by default...

While these may not need to be cryptographically secure, I don't think they
need to be state-dependent as well. Probably no one would look at the
function name and think that it depends on the module global state.

php_random_int() doesn't have any state anywhere (except OS) and can
generate the requested random number. I don't see any problem with these
functions using php_random_int() as a random number source.

Regards,
Go Kudo


2021年9月4日(土) 1:02 Nikita Popov :

> On Thu, Sep 2, 2021 at 5:10 PM Go Kudo  wrote:
>
>> Hi Internals.
>>
>> Expanded from the previous RFC and changed it to an RFC that organizes the
>> whole PHP random number generator. Also, the target version has been
>> changed to 8.2.
>>
>> https://wiki.php.net/rfc/rng_extension
>> https://github.com/php/php-src/pull/7453
>>
>> Hopefully you will get some good responses.
>>
>
> This looks pretty nice to me. A few bits of feedback:
>
>  * Unlike the previous versions of the RFC, this one also moves all of the
> existing RNG-related functionality from ext/standard to ext/random. Why
> does it do this? This doesn't really seem related to the problem this RFC
> is solving.
>
>  * Regarding the abstract class Random\NumberGenerator: You currently need
> the abstract class, because php_random_ng is tied to the object. An
> alternative design that would allow Random\NumberGenerator to be an
> interface would be to make it independent of the object, such that the
> structure can be allocated in the Random constructor for userland
> implementations. Of course, internal implementations could still embed it
> as part of their objects -- just don't make it a requirement.
>
>  * The future scope mentions: "Changes random source to php_random_int() a
> shuffle(), str_shuffle(), and array_rand()". I don't think it makes sense
> to switch these functions to use cryptographic randomness by default...
>
> Regards,
> Nikita
>

Re: [PHP-DEV] Adding a way to disable the stat cache

[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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Adding a way to disable the stat cache

[Kevin Lyda]

On Fri, Sep 3, 2021 at 4:24 PM Nikita Popov  wrote:
> Just to throw it out there: Maybe we should clear the stat cache when 
> functions in the exec family are used? Even if we allow disabling the stat 
> cache, I think we can easily avoid that particular footgun. And if calls to 
> external binaries are involved we likely don't have to worry about stat 
> overhead.

This code also breaks:

https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Random Extension 3.0

[Nikita Popov]

On Thu, Sep 2, 2021 at 5:10 PM Go Kudo  wrote:

> Hi Internals.
>
> Expanded from the previous RFC and changed it to an RFC that organizes the
> whole PHP random number generator. Also, the target version has been
> changed to 8.2.
>
> https://wiki.php.net/rfc/rng_extension
> https://github.com/php/php-src/pull/7453
>
> Hopefully you will get some good responses.
>

This looks pretty nice to me. A few bits of feedback:

 * Unlike the previous versions of the RFC, this one also moves all of the
existing RNG-related functionality from ext/standard to ext/random. Why
does it do this? This doesn't really seem related to the problem this RFC
is solving.

 * Regarding the abstract class Random\NumberGenerator: You currently need
the abstract class, because php_random_ng is tied to the object. An
alternative design that would allow Random\NumberGenerator to be an
interface would be to make it independent of the object, such that the
structure can be allocated in the Random constructor for userland
implementations. Of course, internal implementations could still embed it
as part of their objects -- just don't make it a requirement.

 * The future scope mentions: "Changes random source to php_random_int() a
shuffle(), str_shuffle(), and array_rand()". I don't think it makes sense
to switch these functions to use cryptographic randomness by default...

Regards,
Nikita

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 03.09.2021 um 17:23 schrieb Nikita Popov :
> Just to throw it out there: Maybe we should clear the stat cache when 
> functions in the exec family are used? Even if we allow disabling the stat 
> cache, I think we can easily avoid that particular footgun. And if calls to 
> external binaries are involved we likely don't have to worry about stat 
> overhead.

While this would make the foot gun a bit smaller it introduces more magic. I'm 
not completely against it but it feels dirty.
On top of that: I hope people using exec and friends are properly escaping 
parameters. Which in our case is a helper function where a clear_stat_cache() 
could easily be added in user land, making it explicit.

Side-note: We should teach people not to use exec style function when normal 
PHP functions work :-)
The following works fine:

https://www.php.net/unsub.php

Re: [PHP-DEV] Adding a way to disable the stat cache

[Nikita Popov]

On Fri, Sep 3, 2021 at 4:08 PM Kevin Lyda  wrote:

> 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?
>
> 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.
>
> However more importantly the current behaviour returns bad data for
> perfectly correct programs. So for example on a unix box...
>
>  passthru('touch foo');
> if (is_file('foo')) {
> echo "Correct\n";
> }
> passthru('rm foo');
> if (is_file('foo')) {
> echo "Incorrect\n";
> }
> ?>
>
> Now this is a silly toy, but imagine using is_file to see if a
> graphics file exists, running an image processing program on it to
> modify it, and then using a stat call to get the file length to
> populate the Content-Length field - it will almost certainly be wrong.
>

Just to throw it out there: Maybe we should clear the stat cache when
functions in the exec family are used? Even if we allow disabling the stat
cache, I think we can easily avoid that particular footgun. And if calls to
external binaries are involved we likely don't have to worry about stat
overhead.

Regards,
Nikita

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christoph M. Becker]

On 03.09.2021 at 16:07, Kevin Lyda wrote:

> 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?
>
> 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.

It seems to me a typical example where the stat cache is useful would be



--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

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?
> 
> 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...
> 
>  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-file-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

Re: [PHP-DEV] [RFC] Random Extension 3.0

[Go Kudo]

> I'm still unclear how I'd write my own NumberGenerator right now.  I
mean, I can extend the class, but I don't have a sense for what I'd do with
it for non-testing/trivial implementations.  You say it's using an internal
function to generate numbers, but in user space what would I do with that?
And when/why would I?

For example, I will create an application that does a lottery. I need to
estimate the load and test it. If I actually use random numbers to draw the
lots, the test results will be different each time.

It is true that this example can be solved by devising a better
implementation of the userland.

If this is the case, you may be wondering why we implement it this way.

Currently, there are several implementations of random number generators
written in PHP.

https://github.com/savvot/random

Although not in this library, I use an in-house interface that is
completely replaceable with random_int() for load testing in my production
brother.

Also, JIT was implemented in PHP 8.0. which has the potential to make it
possible to write in PHP what would otherwise have to be implemented in C
due to execution speed issues. In fact, the random number generator written
in PHP for my tests shows a significant performance improvement when JIT is
enabled. The ability to have a workable random number implementation in
userland should be useful for future extensions.

> Is the intent that I should stop using random_int()?

No, it's not. random_int() is a safe and easy CSPRNG, and is recommended
for future use.
The advantage of using Random\NumberGenerator\Secure is that it can shuffle
strings/arrays using the same random number source as random_int().

Something that is not included in this RFC but that I would like to
deprecate in the future is the mt_srand (srand) function. These have
internal state and are very harmful for extensions such as Swoole:

Also, shuffle() and str_shuffle() are very good functions, but I don't
think they should use the random number source generated by mt_srand. The
user may unintentionally use an unsecured random number.

I apologize for the difficulty in conveying this message. I've revised the
wording.

> Changes random source to php_random_int() in shuffle(), str_shuffle(),
and array_rand() .

2021年9月3日(金) 23:04 Larry Garfield :

> On Fri, Sep 3, 2021, at 8:55 AM, Go Kudo wrote:
> > Thank you.
> >
> > > Why is the number generator a parent class rather than an interface?
> >
> > This is an implementation limitation. I could not find a way to define my
> > own object handler in interface.
> > As Nikita pointed out in a previous suggestion, the NumberGenerator now
> > uses php_random_ng_algo_user to generate random numbers faster than
> before,
> > even if it is a userland implementation.
>
> I'm still unclear how I'd write my own NumberGenerator right now.  I mean,
> I can extend the class, but I don't have a sense for what I'd do with it
> for non-testing/trivial implementations.  You say it's using an internal
> function to generate numbers, but in user space what would I do with that?
> And when/why would I?
>
> > > You don't mention the CSPRNG functions at all.
> >
> > This is a mistake. I have corrected it. Thanks!
>
> I'm still not clear on the intent here.  Is the intent that I should stop
> using random_int()?  And if so, replace it with... what?  Do I have to
> supply a specific non-default generator?  That makes the usability worse,
> and more likely to be gotten wrong.
>
> Also, in future scope you you have this sentence, which makes little sense:
>
> >> Replace random_bytes() with random_bytes() for random numbers used in
> shuffle(), str_shuffle(), and array_rand().
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Adding a way to disable the stat cache

[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?

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.

However more importantly the current behaviour returns bad data for
perfectly correct programs. So for example on a unix box...



Now this is a silly toy, but imagine using is_file to see if a
graphics file exists, running an image processing program on it to
modify it, and then using a stat call to get the file length to
populate the Content-Length field - it will almost certainly be wrong.

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.

Kevin

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Random Extension 3.0

[Larry Garfield]

On Fri, Sep 3, 2021, at 8:55 AM, Go Kudo wrote:
> Thank you.
> 
> > Why is the number generator a parent class rather than an interface?
> 
> This is an implementation limitation. I could not find a way to define my
> own object handler in interface.
> As Nikita pointed out in a previous suggestion, the NumberGenerator now
> uses php_random_ng_algo_user to generate random numbers faster than before,
> even if it is a userland implementation.

I'm still unclear how I'd write my own NumberGenerator right now.  I mean, I 
can extend the class, but I don't have a sense for what I'd do with it for 
non-testing/trivial implementations.  You say it's using an internal function 
to generate numbers, but in user space what would I do with that?  And when/why 
would I?

> > You don't mention the CSPRNG functions at all.
> 
> This is a mistake. I have corrected it. Thanks!

I'm still not clear on the intent here.  Is the intent that I should stop using 
random_int()?  And if so, replace it with... what?  Do I have to supply a 
specific non-default generator?  That makes the usability worse, and more 
likely to be gotten wrong.

Also, in future scope you you have this sentence, which makes little sense:

>> Replace random_bytes() with random_bytes() for random numbers used in 
>> shuffle(), str_shuffle(), and array_rand().

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Random Extension 3.0

[Go Kudo]

My apologies. I had skipped one.

> And either way it needs more clarity about how you'd write one for reals.

Added a simple example comparing it to mt_rand. What do you think of this?

2021年9月3日(金) 3:26 Larry Garfield :

> On Thu, Sep 2, 2021, at 10:10 AM, Go Kudo wrote:
> > Hi Internals.
> >
> > Expanded from the previous RFC and changed it to an RFC that organizes
> the
> > whole PHP random number generator. Also, the target version has been
> > changed to 8.2.
> >
> > https://wiki.php.net/rfc/rng_extension
> > https://github.com/php/php-src/pull/7453
> >
> > Hopefully you will get some good responses.
> >
> > Regards,
> > Go Kudo
>
> This looks pretty nice to my unskilled eye.  Two questions.
>
> 1) Why is the number generator a parent class rather than an interface?
> It seems like an interface target.  And either way it needs more clarity
> about how you'd write one for reals.  (It returns an int, so does that mean
> getBytes() just derives from a series of ints?)
>
> 2) You don't mention the CSPRNG functions at all.  Is there any intention
> to fold those into this model as well, or to leave those as is?  Or is the
> Secure generator implementation intended to replace those?  It's unclear
> here.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Random Extension 3.0

[Go Kudo]

Thank you.

> Why is the number generator a parent class rather than an interface?

This is an implementation limitation. I could not find a way to define my
own object handler in interface.
As Nikita pointed out in a previous suggestion, the NumberGenerator now
uses php_random_ng_algo_user to generate random numbers faster than before,
even if it is a userland implementation.

> You don't mention the CSPRNG functions at all.

This is a mistake. I have corrected it. Thanks!

I will keep an eye on it throughout the next week, and if there are no
additional responses, I will start voting the week after next.

Regards,
Go Kudo

2021年9月3日(金) 3:26 Larry Garfield :

> On Thu, Sep 2, 2021, at 10:10 AM, Go Kudo wrote:
> > Hi Internals.
> >
> > Expanded from the previous RFC and changed it to an RFC that organizes
> the
> > whole PHP random number generator. Also, the target version has been
> > changed to 8.2.
> >
> > https://wiki.php.net/rfc/rng_extension
> > https://github.com/php/php-src/pull/7453
> >
> > Hopefully you will get some good responses.
> >
> > Regards,
> > Go Kudo
>
> This looks pretty nice to my unskilled eye.  Two questions.
>
> 1) Why is the number generator a parent class rather than an interface?
> It seems like an interface target.  And either way it needs more clarity
> about how you'd write one for reals.  (It returns an int, so does that mean
> getBytes() just derives from a series of ints?)
>
> 2) You don't mention the CSPRNG functions at all.  Is there any intention
> to fold those into this model as well, or to leave those as is?  Or is the
> Secure generator implementation intended to replace those?  It's unclear
> here.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 02.09.2021 um 13:15 schrieb Kevin Lyda :
> Removing it completely would be ideal, however a number of people objected
> in the linked bug. And while it's not needed in modern Unix operating
> systems, it's not clear if Windows might benefit from this.


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?

Just curious,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Adding a way to disable the stat cache

[Nikita Popov]

On Thu, Sep 2, 2021 at 10:27 AM Kevin Lyda  wrote:

> PHP has a stat cache which is... unfortunate. As noted in this bug from
> 2004[0] it causes a number of issues for PHP users and is irrelevant
> in modern operating systems. Heck, it's not even useful in OS's people
> might consider ancient at this point.
>
> I have a PR[1] to fix this, but had not noticed it had been referred to
> this mailing list.  I'll need fix the PR at this point as the code has
> drifted, but before I do, can whatever discussion happen so that the PR
> will be accepted?  The change I've made will allow people to disable the
> cache so that it won't cause errors and it leaves the current broken
> behaviour in place.  So there's no real change to the user experience
> except they now have a tool to disable buggy behaviour.  I feel that
> this is the least intrusive way to fix this bug.
>
> In the discussion on the bug there was resistance to getting rid of the
> cache so this was the solution proposed in 2007 and seemed reasonable.
> The default behaviour remains but can be turned off by people who want
> it off - and there are a number of people who would like it off.
>
> Is this an acceptable solution? Would this functionality be accepted
> either via my PR or another.
>
> Kevin
>
> [0]: https://bugs.php.net/bug.php?id=28790
> [1]: https://github.com/php/php-src/pull/5894
>

Looks like a reasonable addition to me.

Regards,
Nikita