Page tree
Skip to end of metadata
Go to start of metadata

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.

    // Option NOT to log certain error-levels eg. E_NOTICE or E_STRICT

Disable TopCollector

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.

    // Don't collection any data for z-push-top
    define('TOPCOLLECTOR_DISABLED', true);

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.

  1. 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.
  2. 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:

    // Don't perform fixstates on upgrade
    define('IGNORE_FIXSTATES_ON_UPGRADE', true);

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.

Introduced parameters:

  • 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:

* Trigger folder re-sync - Settings
* Set these thresholds to fine tune the Folder re-sync Triggering 
// Max block deletions quantity threshold to evaulate a possible Folder re-sync trigger
define('DELETION_COUNT_THR', 1000);
// Ratio between the number of deletions commands received and the remaining folder elements after the deletions.
// Over this threshold a Folder re-sync is triggered.
define('DELETION_RATIO_THR', 1);

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:

* Retry loop when writing file state machine data to disk
* FILE_STATE_WRITE_ATTEMPTS: number of attempts
* FILE_STATE_WRITE_SLEEP: ms to sleep between attempts
define('FILE_STATE_WRITE_SLEEP', 200);
  • No labels