Hi,
On Tue, Sep 7, 2021, 5:49 PM Kamil Tekiela wrote:
> It's WSL2
> uname -r
> 5.4.72-microsoft-standard-WSL2
>
no need to test on wsl2, that's a dockerized linux.
best,
Pierre
>
It's WSL2
uname -r
5.4.72-microsoft-standard-WSL2
WSL1 or WSL2? afaik they have significant performance differences, and we
should only consider WSL2 as WSL1 is being deprecated afaik
On Tue, 7 Sept 2021 at 12:31, Kamil Tekiela wrote:
> > It would be great if someone on
> Windows and macos could repeat this experiment
>
> I ran this on Windows
> It would be great if someone on
Windows and macos could repeat this experiment
I ran this on Windows and I got the following results:
Native Windows build:
Without cache
real0m31.170s
user0m0.000s
sys 0m0.000s
With cache
real0m0.694s
user0m0.000s
sys 0m0.000s
Ubuntu
On Fri, Sep 3, 2021 at 7:10 PM Kevin Lyda wrote:
> [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?
On Mon, Sep 6, 2021, 10:50 PM Christian Schneider
wrote:
> Am 06.09.2021 um 16:46 schrieb Pierre Joye :
> > Also as someone mentioned here afterwards, instead of removing it
> > straight away, I would go with the flag first, less risky :)
>
> Out of curiosity: Do you think disabling the stat
Am 06.09.2021 um 16:46 schrieb Pierre Joye :
> Also as someone mentioned here afterwards, instead of removing it
> straight away, I would go with the flag first, less risky :)
Out of curiosity: Do you think disabling the stat cache could be harmful?
If no, why make it an option?
If yes, should we
On Mon, Sep 6, 2021 at 7:05 PM Christoph M. Becker wrote:
>
> On 06.09.2021 at 14:00, Pierre Joye wrote:
>
> > On Mon, Sep 6, 2021, 6:14 PM Benjamin Eberlei wrote:
> >
> >> On Fri, Sep 3, 2021 at 11:51 PM Hans Henrik Bergan
> >> wrote:
> >>
> >> The stat cache does not necessarily solve this
Am 05.09.2021 um 13:30 schrieb Kevin Lyda :
> Any more thoughts on https://github.com/php/php-src/pull/5894 ?
> I've resolved the merge conflict. It would be nice to close out this bug.
For the record in case it was missed:
If we deem the stat cache to be useless I'd rather remove it completely
On 06.09.2021 at 14:00, Pierre Joye wrote:
> On Mon, Sep 6, 2021, 6:14 PM Benjamin Eberlei wrote:
>
>> On Fri, Sep 3, 2021 at 11:51 PM Hans Henrik Bergan
>> wrote:
>>
>> The stat cache does not necessarily solve this issues though, only in very
>> limited cases where you work with the *same*
On Mon, Sep 6, 2021, 6:14 PM Benjamin Eberlei wrote:
> On Fri, Sep 3, 2021 at 11:51 PM Hans Henrik Bergan
> wrote:
>
>
> The stat cache does not necessarily solve this issues though, only in very
> limited cases where you work with the *same* file over and over again. The
> stat cache only ever
On Fri, Sep 3, 2021 at 11:51 PM 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
On Fri, Sep 3, 2021 at 10:51 PM 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
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
>
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
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,
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:
>
>
[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
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
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
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
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
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
>>
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
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
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
Just as an aside, Lynn and Peter are two more people who have had this
issue - in addition to the folks mentioned in the various bugs about this.
Really would like clear guidance on what's needed to move the PR on
once I resolve the current merge conflict.
On Thu, Sep 2, 2021 at 9:49 AM Peter
On Thu, 2 Sept 2021 at 09:27, Kevin Lyda wrote:
> 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.
>
Is there any good reason not to remove it completely?
I've been bitten by the stat cache before
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
29 matches
Mail list logo
