unit
unit copied to clipboard
nginx
Support for .user.ini files (PHP)
Hello,
.user.ini file is good for users without access to server configuration and it should allow changes only variables with PHP_INI_PERDIR/PHP_INI_ALL flags.
Now my users are using .user.ini to reconfigure their applications (php-fpm), so it will good to still have that possibility with Unit.
More about .user.ini: http://php.net/manual/en/configuration.file.per-user.php
Any chances for support for it?
I think this is #543? Maybe add 'Fixes #160' in the pull request to auto close this when/if it gets merged Btw, @mar0x do you plan to merge it?
Regarding https://github.com/nginx/unit/pull/543/files#r714593715:
Thinking more about .user.ini, I don't know if you wanna allow live config this way. Maybe to follow what other PHP application servers (mostly apache2/mod_php and PHP-FPM) do and developers expect, but that implies checking the ttl on every request or at main loop and then checking and loading configs recursively (from app's root up to the requested php script) once the cache expires. That is the reason nginx does not have an .htaccess equivalent in the first place, but again, it is a matter of how closely you wanna follow PHP-FPM spec. It's an obvious performance trade-off.
Other option is to close this as wont fix and explain why, maybe with a benchmark, like this.
We definitely don't want additional syscalls on every request. While sometimes it may be handy, but the overhead isn't worth it. I'm sure that most users don't really need it updated on each request and, at the same time, they don't realise the costs.
It won't actually be updated on every request. TTL is checked on every request, and if expired, then it will be updated. But I'm mostly on side of performance. Just wanted to point out that it is a necessary trade-off if you wanna follow PHP-FPM spec...
TTL cache may work good or not. First of all, the cache isn't shared between processes. As a result, if you have 50 processes, then it can be up to 50 scans for each entry even within TTL. If the processes configured to scale dynamically, then situation will be even worse as each process starts up with a clean cache.
At the same time, I guess that if we just scan all the directory tree for .user.ini files and load them once at the moment of creating/updating/reloading the PHP app in Unit, then that won't give any additional overhead in runtime and will work well for almost all users. We can add it as an optional mode, that will work by default, unless a user wants the classic behaviour and turns it off in the Unit config. What do you think?
I think it is a good approach. Reloading Unit is just a matter of doing an API call anyway...
Ping.
Hello, Are you interested in this feature? I'll close the PR, since the design was rejected. However, feel free to open a new one redesigned with the things talked in this issue.
Cheers,
Alex
