; Production lsphp overrides — mirrors configs/prod-php.ini for the FPM
; image, adapted for LSAPI defaults. Dropped into /usr/local/lsws/lsphpNN/etc/php.d/

memory_limit = 256M
post_max_size = 384M
upload_max_filesize = 256M
max_input_vars = 2000
max_execution_time = 60
max_input_time = 120

expose_php = Off
short_open_tag = Off

display_errors = Off
log_errors = On
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
zend.exception_ignore_args = On

session.save_handler = files
session.use_cookies = 1
session.use_only_cookies = 1
session.use_strict_mode = 0
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 1440

opcache.enable = 1
; Sized to fit Divi + WooCommerce + WP core comfortably without eviction
; thrash. Per-instance because shmem is per-process-RSS on Linux cgroups
; (vs PHP-FPM's COW-shared model — one lsphp PARENT per httpd worker in
; OLS, each with its own opcache segment).
;
; Sizing history:
;   128 MB / 10000 files (original): blew 800+ MiB shmem under setUIDMode 2
;     because that gave 8+ lsphp instances each at 128 MB → 1+ GiB shmem.
;   32 MB / 4000 files (2026-06-02): solved the shmem problem but caused
;     opcache eviction thrash on Divi/WC sites (3000+4000 unique PHP files
;     each); manifested as ~40% sustained CPU on alphaoneaminos and
;     elevated OOM cycling on brain-jar (5378 oom_kills/9h on 2026-06-03).
;   64 MB / 8000 files (current): fits Divi+WC bytecode without eviction;
;     N lsphp × 64 MB ≈ 512 MiB shmem worst case, still acceptable.
;
; Override per-site via OPCACHE_MEMORY_MB / OPCACHE_MAX_FILES env vars
; (panel: Advanced Tuning → OpCache size) for outliers.
opcache.memory_consumption = 64
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 8000
opcache.revalidate_freq = 60
opcache.enable_cli = Off

output_buffering = 4096
default_charset = "UTF-8"

file_uploads = On
max_file_uploads = 20

soap.wsdl_cache_enabled = 1
soap.wsdl_cache_dir = "/tmp"
soap.wsdl_cache_ttl = 86400
soap.wsdl_cache_limit = 5