PHP (en)

PHP config files (FPM, CLI and Hubzilla)

These are excerpts from the respective files, there’s no point in showing all (default) options. Again, the paths may vary depending on your distribution, these are mine:

/etc/php/fpm-php8.3/php.ini

[PHP]
expose_php = Off

max_execution_time = 30
max_input_time = -1
memory_limit = 1024M
post_max_size = 16M
file_uploads = On
upload_max_filesize = 16M
max_file_uploads = 20

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off

These should be plain. A note about max_execution_time: Occasionally there’s a problem with hubzilla’s queue workers, resulting in lots of stalled queries in the database, which itself has got two negative effects if unchecked: Eating up all database’s connections and resulting in a load of more than 200. This - together with apache’s MPM timeout and mariadb’s timeout - mitigates the problem.

/etc/php/cli-php8.3/php.ini

[PHP]
expose_php = On

max_execution_time = 0
max_input_time = -1
memory_limit = 2048M

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
ignore_repeated_errors = Off
ignore_repeated_source = Off

post_max_size = 8M

At the cli, max_execution_time isn’t an issue, so there’s no harm having no limit. Same goes to memory_limit and post_max_size, which have slightly different values than it’s fpm cousin.

/etc/php/fpm-php8.3/fpm.d/ www.conf

[www]

pm = static
pm.max_children = 50
; pm.start_servers = 30
;pm.min_spare_servers = 15
;pm.max_spare_servers = 75
;pm.process_idle_timeout = 10s;
;pm.max_requests = 500

pm.status_path = /status
ping.path = /ping

php_admin_value[error_log] = /var/log/pm-php.www.log
php_admin_flag[log_errors] = on

These settings also heavily depends on your setup. I’ve chosen static instead of dynamic. It’s more responsive and better suited in a heavy server environment (like this hub), there’s no delay waiting for spare servers to start, the dynamic - disabled - configuration is commented out (pm.start_servers and friends). It’s more responsive and faster that way, but there’s one downside: If all processes are used up (50), new sessions are not working¹ On the other hand, existing session are not effected, and anyway there’s always a limit (CPU, RAM, whatever) so you have to do some balancing/tuning. Again, the /status and /ping are for monitoring.

.htconfig.php

error_reporting(E_ERROR | E_PARSE );
ini_set('error_log','php.out');
ini_set('log_errors','1');
ini_set('display_errors', '0');

# Session
App::$config['system']['session_custom'] = true;
App::$config['system']['session_save_handler'] = "redis";
App::$config['system']['session_save_path'] = "tcp://127.0.0.1:6379";

First of all, I don’t care about warnings - warnings are only active when debugging a problem. Otherwise, php.out will grow to an enormous size. Second, and this is one of the most important performance gains: Do not store sessions in the database! Although this is the default, it’s also one of the best ways to reduce the database perfomance/increase your load. It’s usually a very bad idea, unless you are running a small hub (or whatever, storing sessions in a database is always a bad idead).

There are two options instead:

1. Store your session on the filesystem, for example in /tmp (often tmpfs, i.e. memory).
2. Use a simple key-value store like Redis.

Using Redis as a session store - although increasing the setup’s complexity - has an advantage over /tmp: In the case of reboot (for example, updates), redis saves it’s data to the filesystem and reloads it after being restarted. This means there’s no session loss, users don’t have to log in again after a reboot and so on. It’s just much more comfortable for users²

Footnotes

1. In fact, I’m getting in this case warning by my monitoring that the site or php-fpm is down- something like gateway timeout. ↩

2. Since I’m a user too, I like it to not having to log in again after a reboot ↩