[DeploySettings]
Available since Exponential 6.0.15 (in development, not in a release yet).
Summary
The group [DeploySettings] of settings/velocity.ini.
File
settings/velocity.ini; override it in settings/override/velocity.ini.append.php, in a siteaccess or in an extension.
Settings
| Setting | Default | Description |
|---|---|---|
| PhpFpmService | auto | exp:velocity deploy: everything a PHP code change needs, in order. The PHP-FPM service it reloads, so the web server in front of this installation (Apache, nginx) runs the new code too: auto find it: the FPM pool named after this installation's hosting domain (/var/www/vhosts/<domain>/..., as Plesk names pools), or one whose configuration names this installation's directory. Looked for in /opt/plesk/php/*/etc/php-fpm.d (Plesk, service plesk-php<XY>-fpm), /etc/php-fpm.d (php-fpm), /etc/php/*/fpm/pool.d (php<X.Y>-fpm) and /etc/opt/remi/php*/php-fpm.d (php<XY>-php-fpm). disabled reload nothing; for an installation served by Velocity alone. <unit> that systemd service, or several, comma-separated. It is a reload (systemctl reload): the master re-reads its code and replaces its workers as each finishes, so no request is dropped. Needs root; run as anyone else, the step is skipped with a note naming the service. |
| PhpFpmReload | auto | Whether that reload is done at all: auto only when needed. When the pool's OPcache revalidates the files (opcache.validate_timestamps on, revalidate_freq at most 60 s, read from the php-fpm binary and the pool file), every changed PHP file is recompiled within revalidate_freq seconds; the step waits that long instead of reloading. Without OPcache it waits for nothing. always reload every time (as before). never neither reload nor wait. A reload is not free, and not for this site alone: the master asks every child of every pool to finish its request and starts no new child until the last one has (up to process_control_timeout, 300 s on Plesk). Each request that arrives in between waits for the longest one running on any site of that PHP version: one open 25 s event stream made the next page wait 22 s, and a long request elsewhere turned waiting requests into 504s (#374). deploy --fpm-reload forces a reload: after a php.ini or pool change, a new PHP extension, or PHP files removed or renamed in place. |
| WarmUpURL[] | (empty array) | Pages requested once each, one after the other, by a background process at the end of a deploy, so the first visitor does not wait while the templates are compiled and the INI, override, translation, design and packed-file caches are rebuilt (and several first visitors do not rebuild them at the same time). Anonymous requests: a site's front page, an admin's login page. The deploy does not wait for them. Empty: no warm-up. WarmUpURL[]=https://www.example.com/ WarmUpURL[]=https://www.example.com/admin/user/login |
| Migrate | disabled | Whether a deploy runs the pending migrations (./console exp:migration:migrate --apply, with its captions, record, commit and push), after the caches of settings and templates and before PHP-FPM and Velocity run the new code. A migration that fails stops the deploy there. enabled: every deploy; disabled: only deploy --migrate. deploy --no-migrate skips them either way. |
See also
Generated example: velocity.ini [DeploySettings]
Added to the reference for Exponential 6.0.15: the 4.x reference had no page for this group. The descriptions are the comment lines of settings/velocity.ini.
Contributors
- Graham Brookins Updated
Comments
Add a comment