There are a few hidden configuration options for certain purposes.
Hide PHP Notifications
If a backend is not E_NOTICE and/or E_STRICT compatible there will be many messages in the log. It's possible to define an own logmask by setting that parameter since Z-Push 2.3.0.
Since Z-Push 2.3.0 it's possible to disable the TopCollector (collect data for the z-push-top tool). This is recommended on busy systems with more than a few hundred concurrent connections. When calling z-push-top all processes are instructed to start collecting data about what they are doing. This can cause a considerable amount of additional load and even bring a system down. On these environments it's recommended to disable the top data collection via the config file, adding the below parameter.
Note: Leaving the TopCollector enabled has impact on performance even without calling z-push-top. Due to this it's recommended to always disable it on busy systems.
Disable "z-push-admin -a fixstates" on upgrade (since Z-Push 2.3.8)
With the introduction of packages for several distributions,
z-push-admin -a fixstates is executed every time the z-push-admin package is upgraded. While this is fine for most of the installations, there are some downsides.
- on bigger installations with many users/state files the operation could take a long time to complete, several hours in the worst case. You don't want your installation process/upgrade to be blocked for this time period.
- when working in clustered z-push environments with several frontend nodes and shared states, each node will check the states on upgrade. This is a huge overhead, especially as normally such setups have a large amount of state files (see point 1).
It's important to understand that fixstates SHOULD be executed after an upgrade, even when using this option. You should plan fixstates as part of the upgrade process and execute it asap after the upgrade. In case of a cluster, it's of course only necessary to be executed once on the states.
Add the following lines to your z-push main config:
Folder re-sync is triggered on deletions ratio threshold (since Z-Push 2.4.2)
Since Z-Push 2.4.2 it's possible to enable the fine tuning of folder re-sync triggering when a client receives a great amount of messages remove requests.
- DELETION_COUNT_THR : Maximum amount of message remove requests received for a folder beyond which a folder re-sync can be considered
- DELETION_RATIO_THR : ratio between "remove requests received count" and "folder remaining elements count".
Folder resync is triggered only if more than DELETION_COUNT_THR remove requests from ICS for a folder are received and the ratio between "requested deleted element count" and "remaining elements count" is greater than DELETION_RATIO_THR
The amount of messages to be deleted threshold is no more hard coded but parametric DELETION_COUNT_THR.
The DELETION_RATIO_THR parameter is used to not trigger folder resync when the count of left messages are a lot more than the deletions.
To activate this behaviour both DELETION_COUNT_THR and DELETION_RATIO_THR parameters have to be defined and set into the config file z-push.conf.php. Otherwise the standard behaviour of re-syncing only over 1000 deletions will be used.
Example of z-push.conf.php:
Retry loop when writing file state machine data to disk (since Z-Push 2.4.4)
To avoid the error "FatalMisconfigurationException: FileStateMachine->SetState(): Could not write state" due to an "Input/output error (2)", a parametric retry loop is added when writing file state machine data to disk.
Into specific enviroments with high traffic (and, i.e., file state on NFS storages) it could happen resource is momentarily not available.
The loop executes up to 3 attempts with 100ms of sleep each when writing data to disk.
it's possible to overwrite the default values for fine tuning. Introduced parameters:
- FILE_STATE_WRITE_ATTEMPTS: number of attempts. If not defined default value is 3
- FILE_STATE_WRITE_SLEEP: ms to sleep between attempts. If not defined default value is 100
Example of z-push.conf.php: