Hidden configuration parameters
There are a few hidden configuration options for certain purposes.
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
define('LOG_ERROR_MASK', ~(E_NOTICE|E_STRICT));
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);
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:
// Don't perform fixstates on upgrade
define('IGNORE_FIXSTATES_ON_UPGRADE', true);
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);
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_ATTEMPTS', 10);
define('FILE_STATE_WRITE_SLEEP', 200);
To use the feature, add the following lines to z-push.conf.php
$specialSyncFilter = array(
"SYSTEM" => SYNC_FILTERTYPE_3MONTHS,
"SYSTEM/99b867e0eac5424982dd39d507add46b1a1500000000" => SYNC_FILTERTYPE_ALL,
"testuser/99b867e0eac5424982dd39d507add46b3a0000000000" => SYNC_FILTERTYPE_1DAY,
);
It's possible to configure a custom sync window for an entire store or a specific folder in a store. Z-Push takes the most accurate configuration. In the above example this means: everything in the public folder will be limited to 3 month, but the specified folder will not be limited (ALL). When testuser syncs his own store the specified folder will not be limited (but if there is a general limitation that one will be honored). If any other user syncs this folder (opened as shared folder) the sync window will be limited to one day.
Disable KOE handling of setting a custom sync timeframe based on the total storesize (since Z-Push 2.5.2)
Add the option to disable KOE handling of setting a custom sync timeframe based on the total storesize.
To use the feature, add the following line to z-push.conf.php
define('DISABLE_KOE_STORESIZE_LIMIT', true);
In high load environments sometimes devices need to wait more time to acquire a memcached mutex. By increasing maxWaitCycles value is possible to prevent memcached to be marked as down if a process cannot acquire the mutex in time. By adding the optional parameter on memcached.conf.php:
// Multiply the wait cycles before setting memcache as down
define('MEMCACHED_MAX_WAIT_CYCLES_MULTIPLIER', 2);
the maxWaitCycles variable is multiplied for the defined factor.