Increase realpath_cache_size default value

[staabm]

the realpath_cache_size can have a strong impact on performance when the cache is full. in times where a lot of classes can be loaded via composer etc. the 16k realpath_cache_size which is the default until now can easily get too small.

---

Summary of all numbers collected within this Issue/Thread:

app/framework	req. real-path-cache in bytes
symfony 3.2.1 demo [1]	600 000
laravel 5.3 demo [2]	130 000
wordpress 4.7 plain[3]	50 000

I can easily get a real-path-cache size of 600 000 when clicking tru the symfony-demo app[1] (using symfony 3.2.1).

with the laravel demo app[2] which is a simple blog with 5 content pages the real-path-cache size is about 130 000 (using laravel5.3).

a plain WP4.7[3] - after the setup and surfing thru all the admin-backend pages the realpath-cachesize is ~50 000. No plugins involved, no real content inside WP added/created. just the very basic setup with the bare minimum you get after the installation process.

the values are calculated using var_dump(realpath_cache_size()); after clicking thru a few pages.
the current default for php is 16 000.. as you see already for this very simple examples you get way more then the default can hold.

tested on ubuntu14lts with php7.0.14

[1] http://symfony.com/blog/introducing-the-symfony-demo-application
[2] https://github.com/bestmomo/laravel5-3-example
[3] https://wordpress.org/download/

Proposed new default: 4096K

[staabm]

for reference: symfony docs recommend to use at least 4096k, so maybe the default should be configured even higher

http://symfony.com/doc/current/performance.html#configure-the-php-realpath-cache
https://www.scalingphpbook.com/blog/2014/02/14/best-zend-opcache-settings.html

most of the "new php frameworks" come with a lot of code bundled via composer.. the php.ini defaults should reflect this changes in the ecosystem IMO.

[krakjoe]

Please could you try to determine the most suitable size for the cache and include your findings/reasoning here: Does the change actually solve the perf problem in those frameworks for example ?

[rlerdorf]

It is hard to say what the most suitable size is, but we have learned that the current default is definitely too small.

[nikic]

Does anyone have data on the average size per path? Just to get an idea how many paths this can actually store.

[staabm]

Let me setup a few demo apps based on some widely used frameworks and see how much they require in the default setup

[krakjoe]

@rlerdorf best case seems to be that we can determine if our reasoning is sound for the new default, and that it generally makes things better for common kinds of projects today ... still it will be too small or too large for some I would suppose.

@nikic I guess @staabm will be able to tell us the average as part of analysis

@staabm excellent stuff, thank you

[staabm]

tested on ubuntu14lts with php7.0.14

I can easily get a real-path-cache size of 600.000 when clicking tru the symfony-demo app[1] (using symfony 3.2.1).

with the laravel demo app[2] which is a simple blog with 5 content pages the real-path-cache size is about 130.000 (using laravel5.3).

the values are calculated using var_dump(realpath_cache_size()); after clicking thru a few pages.
the current default for php is 16.000.. as you see already for this very simple examples you get way more then the default can hold.

[1] http://symfony.com/blog/introducing-the-symfony-demo-application
[2] https://github.com/bestmomo/laravel5-3-example

---

I agree that we cannot define a value which works for everything but at least for the a size of such demos apps should be the goal. the value of 4096K - as the symfony docs suggests - sounds like a good default.

In case you guys think symfony is more then most people need, we could also start with e.g. 2048k.

Opinions?

[krakjoe]

Please can you also test a wordpress install, and one or two of the larger projects from oss-perf benchmarks ?

Thanks for putting in all the effort so far ;)

[staabm]

@krakjoe I have no VM available which fullfills all the requirements of the oss-perf benchmarks.

Instead I found a great article by @jpauli which describes the background and consequences of this setting very well [1]. TLDR is that php starts doing lots of filesystem IO when the realpath-cache is full. He also claims that the default is way too small.

IMO this should be enough evidence for our case.

[1] http://jpauli.github.io/2014/06/30/realpath-cache.html

[krakjoe]

@staabm tbh that doesn't tell us anything we didn't already know :)

I didn't mean run the benchmarks, I just meant run drupal, wordpress, or something other than the symfony example app ... oss-perf just happens to have a list is all ...

If you're not able, it will have to wait until I can do some testing, maybe weekend ... or anyone else is free to do it ...

[staabm]

@krakjoe oh I see... let me setup a WP demo..

[staabm]

so finally some WP numbers.. a plain WP4.7 - after the setup and surfing thru all the admin-backend pages the realpath-cachesize is ~50.000.

No plugins involved, no real content inside WP added/created. just the very basic setup with the bare minimum you get after the installation process.

tested on ubuntu14lts with php7.0.14

added a summary of all the numbers into the issue description at the top.

[jpauli]

I would say that in 2017, the default number is ridiculously too low.
Drupal, WP, Framework based apps , etc.... all make use of OOP, which dictates to put one class per file.

We end up loading LOTS of files just to server one HTTP request, and the RP cache saturates very quickly with such apps.

[krakjoe]

@jpauli what do you think about the current suggestion of 4096k ?

It's over and above what your average WP may need, and should be enough to satisfy a good portion of framework based applications out-of-the-box. So I'm happy with it, I think, but would also be happy if it were smaller - since symfony/laravel/framework based applications do require additional code, there's not a reasonable way to guess what they will need, other than to go by what the framework authors are suggesting (which is what this suggested number is).

Some more input on the specific numbers would be excellent ;)

[jpauli]

I'm OK with the suggestion.

Any admin would anyway tune this number to cope with his need, php.ini-production is just a hint about an average application.

[rlerdorf]

I am ok with it as well, although I would hope 4096k is at the upper end of average applications. I don't have anything that uses more than 2048k and most sites I have checked are below 1024k.

…

-Rasmus

On Thu, Jan 5, 2017 at 9:33 AM, jpauli ***@***.***> wrote: I'm OK with the suggestion. Any admin would anyway tune this number to cope with his need, php.ini-production is just a hint about an average application. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2271 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADVcc9spHN9B0vVVaE3yy-LrUhbHdjRks5rPSl-gaJpZM4LZanN> .

[krakjoe]

Merged 8e39a27 d5a1c5a c9abe87

Thanks.