# CloudLinux OS Pro Components

# Introduction

CloudLinux OS Shared Hosting Pro was developed with shared hosting in mind. It’s a state-of-the-art operating system that gives shared hosting providers what they need: advanced automation, deep-look performance analytics, and centralized monitoring tools.

It includes additional tools to expand the functionality.

To activate the CloudLinux OS Shared Pro you have to purchase a Shared Pro license first, or upgrade the existing one from the cln.cloudlinux.com then activate a license on a server using the same instructions just with a new key.

# AccelerateWP

# Getting started

AccelerateWP carries a suite of optimization features that can be enabled and automatically configured for the end user's site.

There are AccelerateWP, AccelerateWP Premium and AccelerateWP CDN feature suites.

AccelerateWP suite is always enabled when AccelerateWP is turned on. Choose whether you want to offer AccelerateWP Premium offer AccelerateWP Premium or CDN (Content Delivery Network) for your users (by opting in) and click "Turn on" to start exploring AccelerateWP.

# Activate AccelerateWP for a single server

Enable AccelerateWP Free for all users on the server via CLI

Enable AccelerateWP Premium for all users on the server via CLI

Once the AccelerateWP suite is enabled by an administrator, end-users will see an AccelerateWP tab in their control panel interface and be able to activate the optimization feature.

When AccelerateWP CDN suite is enabled by the administrator, end-users will get 1 GB of CDN traffic and be able to activate the feature to use until the limit is reached. Once the 1GB limit is reached - the end-user will be suggested to extend the CDN limit by purchasing a CDN plan using WHMCS or 3'd party billing.

When the AccelerateWP Premium suite is enabled by the administrator, end-users will see the free Object Caching feature in their interface. If current CloudLinux license gives access to billable features - end-users will see Image Optimization and Critical CSS features as well. but cannot activate the feature unless they purchase the feature using WHMCS or 3'd party billing.

# Activate AccelerateWP Free on all servers via Centralized Monitoring

It is possible to activate AccelerateWP Free on all compatible servers via the Centralized Monitoring UI or via the CLN UI. Once Activate button is clicked - AccelerateWP Free will be set up automatically on all compatible servers within couple of minutes.

# Activate AccelerateWP Premium on all servers via Centralized Monitoring

Starting from lve-utils-6.5.11-1 it is possible to activate AccelerateWP Premium via Centralized Monitoring as well.

AccelerateWP Premium will be activated on all compatible servers once activation button is clicked and upgrade url is provided. Before using AccelerateWP Premium features - all end-users will be requested to upgrade to Premium plan using provided upgrade url.

# AccelerateWP suite

This is a basic suite which includes AccelerateWP base feature: a WordPress optimization plugin that provides full page caching, GZIP compression and some other useful optimizations.

AccelerateWP suite limitations

• the website must be on an Apache or LiteSpeed web server;
• the website must be on a server with CloudLinuxOS Shared Pro, Solo, or Admin license
• the website must use PHP version 7.3 or higher.
• the WordPress version must be 5.8 and higher.
• no other WordPress Caching plugins must be installed.
• WordPress should not be running in Multisite mode.

# AccelerateWP Premium suite

Starting from accelerate-wp-1.9-18 - AccelerateWP Premium suite includes both free and billable optimization features. The available features depend on the CloudLinux license installed on the server.

For more information on how to set up a CloudLinux license with AccelerateWP Premium billable features, see Setup CloudLinux license with AccelerateWP Premium billable features

Free features

• Object Caching;

Billable features

• Image Optimization;
• Critical CSS;

Once a server is licensed with CloudLinux and has paid features enabled, both free and billable features become available. If the license does not include paid features, only free features will be accessible.

Object Caching feature.

The Object Caching mechanism stores database query results in additional storage for quick access. This mechanism is beneficial in cases if a website needs to process multiple pages per second as requests come in and may be helpful in cases when full-page caching cannot be used, e.g. on personalized pages.

Image Optimization feature

Critical CSS feature

Premium suite limitations

• the website must be on an Apache or a LiteSpeed web server;
• the website must be on a server with CloudLinuxOS Shared Pro, Solo, or Admin license
• the website must use one of the following PHP handlers:
  • php-fpm
  • lsapi
• the website must use PHP version 7.2 or higher.
• the WordPress version must be 3.7 and higher.
• no other WordPress Caching plugins must be installed.
• the Snuffleupagus must be turned off.
• WordPress should not be running in Multisite mode.

# Administrator interface

# Overview

In the CloudLinux Manager → AccelerateWP tab an administrator has the opportunity to provide end-users with a suite of features, which on its turn could be activated by end-users.

Once the feature suite is enabled by the administrator, end-users will see an AccelerateWP tab in their control panel interface and be able to activate the optimization feature.

# Suites usage statistics

When AccelerateWP is enabled, the AccelerateWP usage statistics are shown.

It includes:

• Active Users block with the total number of users and number of users who have activated the optimization feature/total users
• Wordpress sites on server block with a total number of WordPress sites and WordPress sites optimized by the feature
• statistics table

Each row in the statistics table represents a particular user.

The first column #of Wordpress sites shows the total number of user's WordPress sites.

The second column AccelerateWP shows a number of user's WordPress sites, optimized by the feature.

To enable premium features, click on the "Activate premium features" link and select the options you want. To integrate functions with billing, you must specify the base URL for the purchase of the function by end users.

In case both AccelerateWP and AccelerateWP Premium feature suites are enabled, the statistics are extended with AccelerateWP Premium metrics.

Please notice the AccelerateWP Premium rows in the Active Users and the Wordpress sites on server blocks, and also the AccelerateWP Premium column in the statistics table.

# Filters

You may use the following filters to browse AccelerateWP statistics slices.

• Users with WordPress sites only filter will show statistics for users who already have WordPress sites; users without WordPress installations will be hidden
• Users with AccelerateWP only filter will show statistics for users who utilize the AccelerateWP optimization feature; users who did not activate AccelerateWP feature will be hidden
• Users with AccelerateWP Premium only filter will show statistics for users who utilize the AccelerateWP Premium (Object Caching) feature; users who did not activate the AccelerateWP Premium feature will be hidden
• Users with CDN Free only filter will show statistics for users who utilize the AccelerateWP CDN feature
• Users with CDN Pro only filter will show statistics for users who utilize the AccelerateWP CDN Pro feature

# AccelerateWP CLI

CLI commands for managing AccelerateWP are provided by those utilities:

• cloudlinux-awp-admin - for administrator-side actions;
• cloudlinux-awp-user - for user-side actions;

Smart Advice CLI for managing optimization advices

Starting from accelerate-wp-1.6-6 AccelerateWP CLI utilities provide CLI versioning which is defined via --api-version option.

# Frequently used commands

# Find all enabled premium users

Note: this can also be viewed from the AccelerateWP tab in CloudLinux Manager

cloudlinux-awp-admin get-stat

# Enable AccelerateWP Free

cloudlinux-awp-admin set-suite --suites=accelerate_wp --allowed-for-all

# Enable AccelerateWP Premium

cloudlinux-awp-admin set-suite --suites=accelerate_wp_premium --visible-for-all

# Enable AccelerateWP Premium for free for all users:

cloudlinux-awp-admin set-suite --suites=accelerate_wp_premium --allowed-for-all

# Set Premium Upgrade URL

cloudlinux-awp-admin set-options --upgrade-url "https://plan.upgrade/splash" 

# Enable AccelerateWP CDN free

All users

cloudlinux-awp-admin set-suite --suites accelerate_wp_cdn --allowed-for-all

Single user or group of users

cloudlinux-awp-admin set-suite --suites=accelerate_wp_cdn --allowed --users=<username1>,<username2>

# Enable AccelerateWP CDN 50GB (example)

Important note: each of these users will become billable to you as soon as you grant this entitlement

All users

cloudlinux-awp-admin set-suite --suites accelerate_wp_cdn_pro --attrs='{"traffic_limit": "50 GB"}' --allowed-for-all

Single user or group of users

cloudlinux-awp-admin set-suite --suites accelerate_wp_cdn_pro --attrs='{"traffic_limit": "50 GB"}' --allowed --users <username>,<username2>

# Revoke access to CDN

All users

cloudlinux-awp-admin set-suite --suites accelerate_wp_cdn_pro --disallowed-for-all

Single user or group of users

cloudlinux-awp-admin set-suite --suites accelerate_wp_cdn_pro --disallowed --users <username>,<username2>

# Set Upgrade URL for CDN

cloudlinux-awp-admin set-options --suite accelerate_wp_cdn_pro --upgrade-url="https://plan.upgrade/cdn-boost"

# Grant users access to ALL premium features

Note - this is the most common and fundamentally the same as the users upgrading using the WHMCS plugin - you will only be billed for the users that activate at least one premium feature

All users

cloudlinux-awp-admin set-suite --suites=accelerate_wp_premium --allowed-for-all

Single user or group of users

cloudlinux-awp-admin set-suite --suites=accelerate_wp_premium --allowed --users=<username1>,<username2>

# Completely disallow access to premium features (including premium SmartAdvice)

All users

cloudlinux-awp-admin set-suite --suites=accelerate_wp_premium --disallowed-for-all

Single user or group of users

cloudlinux-awp-admin set-suite --suites=accelerate_wp_premium --disallowed --users=<username1>,<username2>

# Enable all features

Use the cloudlinux-awp-admin enable-feature CLI command to ensure the best performance for every WordPress user. This CLI command scans the server for all WordPress sites, then activates the AccelerateWP feature suite. Activation is skipped for any sites with existing page caching or feature incompatibilities. Note: Please make sure your AccelerateWP version is >= 1.2-2 before proceeding. Scan the server in background mode and activate AccelerateWP on those WordPress sites where it is possible:

cloudlinux-awp-admin enable-feature --all

# Check feature activation status

cloudlinux-awp-admin enable-feature --status

# cloudlinux-awp-admin

cloudlinux-awp-admin --api-version <api_version> <command>

supported commands for --api-version 1:

• set-suite - manage optimization suites;
• set-options - manage server wide settings;
• get-report - get per user information about optimization suites statuses (allowed/disallowed) and usage of specific suites;
• generate-report - generate information, that is obtained via get-report command;
• get-stat - get total information about suites statuses (allowed/disallowed/visible) and usage of optimization features;
• enable-feature - activate free AccelerateWP feature to all users on the server;
• object-cache-banner - manage Redis Object Cache Pro banner visibility in WordPress (hide or show banner for specific WordPress site);

All CLI responses contain result field which says was call successful or not.

• {"result": "success"} - in case of successful call
• {"result": "ERROR_STRING"} - in case of unsuccessful call, result contains string with error details. Response also could have context field to provide additional error info, e.g: username, optimization suite or feature, etc. Example:

{
    "context": {
        "suite": "accelerate_wp_cdn"
    },
    "result": "Suite %(suite)s is not visible for users and so cannot be allowed in billing. Activate the suite on server first. Contact your hoster if you don`t have an access to the server.",
    "timestamp": 1691136964.3719108
}

# Manage AccelerateWP optimization suites

--api-version 1

supported suites:

• accelerate_wp - AccelerateWP Free features;
• accelerate_wp_premium - AccelerateWP Premium features;
• accelerate_wp_cdn - AccelerateWP CDN 1 GB;
• accelerate_wp_cdn_pro - AccelerateWP CDN Pro (50GB by default);

supported actions for specific user(s):

• --allowed - make features of optimization suite ALLOWED to be activated by end-user;
• --disallowed - make features optimization suite DISALLOWED to be activated by end-user;

cloudlinux-awp-admin --api-version 1 set-suite --suites=<suites_comma_separated> --users=<usernames_comma_separated> (--allowed | --disallowed) [--attrs=<json_string>]

Examples of CLI commands to disable undesired optimization suite(s) for a single user.

To disable the AccelerateWP suite:

cloudlinux-awp-admin --api-version 1 set-suite --suites=accelerate_wp --disallowed --users=<username>

To disable the AccelerateWP Premium suite:

cloudlinux-awp-admin --api-version 1 set-suite --suites=accelerate_wp_premium --disallowed --users=<username>

To disable the AccelerateWP CDN suite:

cloudlinux-awp-admin --api-version 1 set-suite --suite=accelerate_wp_cdn --disallowed --users=<username>

To disable the AccelerateWP CDN Pro suite:

cloudlinux-awp-admin --api-version 1 set-suite --suite=accelerate_wp_cdn_pro --disallowed --users=<username>

To enable CDN Pro for a particular user:

cloudlinux-awp-admin --api-version 1 set-suite --suites accelerate_wp_cdn_pro --allowed --users=<username>

To disable all suites:

cloudlinux-awp-admin --api-version 1 set-suite --suites=accelerate_wp,accelerate_wp_premium,accelerate_wp_cdn,accelerate_wp_cdn_pro --disallowed --users=<username>

To define CDN traffic limit for AccelerateWP CDN Pro optimization suite (50GB limit is by default):

cloudlinux-awp-admin --api-version 1 set-suite --suites accelerate_wp_cdn_pro --allowed --users username1 --attrs='{"traffic_limit": "100 GB"}'

supported traffic limits:

• 50 GB - default traffic limit, if no --attrs passed on set-suite;
• 100 GB
• 250 GB
• 500 GB
• 1 TB
• 2.5 TB
• 5 TB
• 10 TB

For all users on the server:

Supported actions for all users:

• --allowed-for-all - make features of optimization suite ALLOWED to be activated for all end-users (and newly created);
• --disallowed-for-all - make features optimization suite DISALLOWED to be activated for all end-users (and newly created);
• --visible-for-all - make features of optimization suite VISIBLE for all end-users (and newly created);

cloudlinux-awp-admin --api-version 1 set-suite --suites=<suites_comma_separated> (--allowed-for-all | --disallowed-for-all | --visible-for-all)

Example of command to enable CDN Pro for all users:

cloudlinux-awp-admin --api-version 1 set-suite --suites accelerate_wp_cdn_pro --users all --allowed-for-all

# Manage AccelerateWP server wide settings

cloudlinux-awp-admin --api-version <api_version> set-options

--api-version 1

cloudlinux-awp-admin --api-version 1 set-options (--icon-visible=<on/off>) | (--object-cache-banner-visible=<on/off>) | (--suite="feature_suite" --upgrade-url="link_to_url") | (--features="optimization_features_comma_separated" --feature-visible=<on/off>)

To make AccelerateWP icon visible or invisible in end-user UI:

cloudlinux-awp-admin --api-version 1 set-options --icon-visible=on

cloudlinux-awp-admin --api-version 1 set-options --icon-visible=off

To change the display of promotional materials for all new installations of the Redis Object Cache module by default, you need to set the visibility setting

cloudlinux-awp-admin --api-version 1 set-options --object-cache-banner-visible=on

cloudlinux-awp-admin --api-version 1 set-options --object-cache-banner-visible=off

To make specific AccelerateWP feature visible or invisible to all users:

supported features:

• critical_css
• image_optimization
• object_cache
• cdn

cloudlinux-awp-admin --api-version 1 set-options --feature-visible=on --features="<features_comma_separated>"

cloudlinux-awp-admin --api-version 1 set-options --feature-visible=off --features="<features_comma_separated>"

To set subscription upgrade url for specific AccelerateWP optimization suite:

for AccelerateWP Premium

cloudlinux-awp-admin --api-version 1 set-options --suite accelerate_wp_premium --upgrade-url="http://mybilling1.com"

for AccelerateWP CDN Pro

cloudlinux-awp-admin --api-version 1 set-options --suite accelerate_wp_cdn_pro --upgrade-url="http://mybilling2.com"

# Generate AccelerateWP suites report for all users on server

--api-version 1

 cloudlinux-awp-admin --api-version <api_version> generate-report (--all | --status)

Start report generation:

 cloudlinux-awp-admin --api-version 1 generate-report --all

It starts data collection in background, so check status of generation by separate command:

 cloudlinux-awp-admin --api-version 1 generate-report --status

Rely on scan_status key to ensure scanning is over, for example if it is still in progress:

 {
    "last_scan_time": 1690198116,
    "result": "success",
    "scan_status": "in_progress",
    "timestamp": 1690199148.6370175,
    "total_users_scanned": 0,
    "total_users_to_scan": 1
}

# AccelerateWP suites statistics

--api-version 1

cloudlinux-awp-admin --api-version <api_version> get-report (--all | --users=<usernames_comma_separated>)

Get suites statistics for all users:

cloudlinux-awp-admin --api-version 1 get-report --all

or for a particular user:

cloudlinux-awp-admin --api-version 1 get-report --users=<username>

This CLI command returns the following information:

• total number of users in the report -- total_users_count
• total number of websites in the report -- total_wordpress_count
• total number of users with particular suite enabled -- total_users_count_active
• total number of websites with particular suite enabled -- total_sites_count_active
• number of websites with a particular suite enabled per each user in the report -- *_sites_count in the users list
• suites visibility status per each user in the report -- suites in the users list
  • possible values for visibility status are: visible, allowed, disabled

The example output for a single user is given below:

{
    "last_scan_time": 1681198804,
    "result": "success",
    "timestamp": 1681203383.3503218,
    "total_sites_count_active": {
        "accelerate_wp": 1,
        "accelerate_wp_premium": 0
    },
    "total_users_count": 1,
    "total_users_count_active": {
        "accelerate_wp": 1,
        "accelerate_wp_premium": 0
    },
    "total_wordpress_count": 2,
    "users": [
        {
            "accelerate_wp_active_sites_count": 1,
            "accelerate_wp_premium_sites_count": 0,
            "suites": {
                "accelerate_wp": {
                    "source": "manual",
                    "status": "allowed"
                },
                "accelerate_wp_premium": {
                    "source": "default",
                    "status": "visible"
                }
            },
            "username": "user16",
            "wp_sites_count": 2
        }
    ]
}

# AccelerateWP features statistics

Get overall AccelerateWP features usage statistics for a server with:

--api-version 1

cloudlinux-awp-admin --api-version 1 get-stat

This CLI command returns the following information:

• number of allowed_users in total and per feature
• number of visible_users in total and per feature
• number of allowed_suites per suite
• number of sites with enabled features in total and per feature -- enabled_sites
• number of users with visible features in total and per feature -- visible_users
• features which are currently allowed -- features_allowed_by_default
• features which are currently visible -- features_visible_by_default

The example output is given below:

{
    "accelerate_wp_suite_enabled_premium_suite_disallowed": 0,
    "accelerate_wp_suite_enabled_premium_suite_visible": 0,
    "allowed_suites": {
        "accelerate_wp": 1,
        "accelerate_wp_cdn_free": 1,
        "accelerate_wp_cdn_pro": 0,
        "accelerate_wp_premium": 1
    },
    "allowed_users": {
        "cdn_free": 1,
        "cdn_pro": 0,
        "critical_css": 1,
        "image_optimization": 1,
        "object_cache": 1,
        "site_optimization": 1,
        "total": 1
    },
    "enabled_sites": {
        "cdn_free": 0,
        "cdn_pro": 0,
        "critical_css": 1,
        "image_optimization": 0,
        "object_cache": 0,
        "site_optimization": 0,
        "total": 1
    },
    "enabled_suites": {
        "accelerate_wp": 0,
        "accelerate_wp_cdn_free": 0,
        "accelerate_wp_cdn_pro": 0,
        "accelerate_wp_premium": 1
    },
    "enabled_users": {
        "cdn_free": 0,
        "cdn_pro": 0,
        "critical_css": 1,
        "image_optimization": 0,
        "object_cache": 0,
        "site_optimization": 0
    },
    "features_allowed_by_default": [
        "cdn",
        "critical_css",
        "image_optimization",
        "object_cache",
        "site_optimization"
    ],
    "features_visible_by_default": [
        "cdn",
        "critical_css",
        "image_optimization",
        "object_cache",
        "site_optimization"
    ],
    "is_accelerate_wp_flag_enabled": false,
    "is_accelerate_wp_icon_enabled": true,
    "result": "success",
    "timestamp": 1690979440.5282295,
    "upgrade_urls": {
        "accelerate_wp_cdn_pro": null,
        "accelerate_wp_premium": null
    },
    "visible_users": {
        "cdn_free": 1,
        "cdn_pro": 0,
        "critical_css": 1,
        "image_optimization": 1,
        "object_cache": 1,
        "site_optimization": 1,
        "total": 1
    }
}

# Activate free AccelerateWP for all WordPress sites on the server

--api-version 1:

cloudlinux-awp-admin --api-version 1 enable-feature (--all | --status)

Use the that command to ensure the best performance for every end-user. CLI command scans a server for all WordPress sites and activates the AccelerateWP free feature suite. It can take up to 2 minutes for a single site. CLI command skips activation for WordPress sites with page caching or feature incompatibilities.

Scan the server in background mode and activate free AccelerateWP plugin on those WordPress sites where it is possible:

cloudlinux-awp-admin --api-version 1 enable-feature --all

The output will state the number of users for the scan and the progress state of the process.

Check activation status:

cloudlinux-awp-admin --api-version 1 enable-feature --status

The output will be either:

• Activation is still in progress,
• Activation is done. The message will state how many users were initially for the scan, a number of WordPress sites with successfully activated suite and the total number of WordPress sites scanned.

# AccelerateWP disable Redis Object Cache Pro banner

--api-version 1

cloudlinux-awp-admin --api-version 1 object-cache-banner (--enable | --disable) (--all | --users=<usernames_comma_separated>)

Depending on the server settings, the WP_REDIS_DISABLE_BANNERS constant will be defined in the wp-config.php file when the module is activated, which affects the display of promotional materials.

To change the WP_REDIS_DISABLE_BANNERS constant for previously installed modules, you need to run a process to update the constant:

Hide on websites where the module is installed

• for all users:
  cloudlinux-awp-admin --api-version 1 object-cache-banner --all --disable
• for specific users (users separated by commas):
  cloudlinux-awp-admin --api-version 1 object-cache-banner --users foo,bar --disable
• for current user (run under the user):
  cloudlinux-awp-user --api-version 1 object-cache-banner --all --disable
• for a specific website (run under the user):
  cloudlinux-awp-user --api-version 1 object-cache-banner --wp-path "" --domain "demo.com" --disable

Display on websites where the module is installed

• for all users:
  cloudlinux-awp-admin --api-version 1 object-cache-banner --all --enable
• for specific users (users separated by commas):
  cloudlinux-awp-admin --api-version 1 object-cache-banner --users foo,bar --enable
• for current user (run under the user):
  cloudlinux-awp-user --api-version 1 object-cache-banner --all --enable
• for a specific website (run under the user):
  cloudlinux-awp-user --api-version 1 object-cache-banner --wp-path "" --domain "demo.com" --enable

If the banner was previously disabled/enabled for the user/website, then for its subsequent activation of the ObjectCache module, the general settings at the server level will be applied. This means that for each user/website we do not store an individual banner disable/enable setting.

# SmartAdvice email reminders

This section outlines the process of managing email notifications from the SmartAdvice plugins. It applies to all users and it is a global (server-wide) setting.

Sending reminder notifications for not activated advices once a month:

cloudlinux-awp-admin --api-version 1 set-options --smart-advice-reminders=<on/off>

# cloudlinux-awp-user

cloudlinux-awp-user --api-version=<api_version> <command>

supported commands:

• enable - activate specific optimization feature on WordPress site;
• disable - deactivate specific optimization feature on WordPress site;
• get - get information of optimization features on all user`s WordPress sites;

Use the following CLI command on behalf of a user

All CLI responses contain result field which says was call successful or not.

• {"result": "success"} - in case of successful call
• {"result": "ERROR_STRING"} - in case of unsuccessful call, result contains string with error details

# Enable optimization feature

--api-version 1

supported features:

• accelerate_wp
• object_cache
• critical_css
• image_optimization

cloudlinux-awp-user --api-version 1 enable --feature <feature> --wp-path <path_to_wordpress> --domain <user_domain> [--ignore-errors]

Use --ignore-errors to ignore WordPress site web-checks after enabling optimization features.

example of enabling Object Caching feature

cloudlinux-awp-user --api-version 1 enable --feature object_cache --wp-path "userwordpresssite" --domain username1.com

Please, make sure --wp-path is same as in "path" key of cloudlinux-awp-user get json output.

Successful response example of enabling feature: rely on feature.enabled field to identify that feature was enabled

{
    "feature": {
        "enabled": true
    },
    "result": "success",
    "timestamp": 1690975273.8860605
}

# Disable optimization feature

--api-version 1

supported features:

• accelerate_wp
• object_cache
• critical_css
• image_optimization

cloudlinux-awp-user --api-version 1 disable --feature <feature> --wp-path <path_to_wordpress> --domain <user_domain>

example of disabling Object Caching feature

cloudlinux-awp-user --api-version 1 disable --feature object_cache --wp-path "userwordpresssite" --domain username1.com

Please, make sure --wp-path is same as in "path" key of cloudlinux-awp-user get json output.

Successful response example of enabling feature: rely on feature.enabled field to identify that feature was enabled

{
    "feature": {
        "enabled": true,
        "visible": true
    },
    "result": "success",
    "timestamp": 1690975273.8860605
}

# AccelerateWP features detailed statistics

--api-version 1

cloudlinux-awp-user --api-version 1 get

The command reports:

• features allowed for a user -- allowed_features
• all user's websites docroots with features information per each wps, which includes:
  • status of each feature -- if the feature is enabled, if the feature is visible
  • issues detected (if any) for each feature
• subscription status (for premium features) -- subscription
• features visible for a user -- visible_features

The example output is given below:

{
    "allowed_features": {
        "accelerate_wp": [],
        "accelerate_wp_premium": []
    },
    "docroots": [
        {
            "domains": [
                "user0.com"
            ],
            "php_handler": "fastcgi",
            "php_version": "plesk-php73-fastcgi",
            "wps": [
                {
                    "features": {
                        "accelerate_wp": {
                            "enabled": false,
                            "issues": [
                                {
                                    "context": {
                                        "plugins": "WP Rocket"
                                    },
                                    "description": "Found conflicting plugins: %(plugins)s.",
                                    "fix_tip": "Deactivate and uninstall the conflicting plugin using the WordPress administration interface.",
                                    "header": "Conflicting plugins are enabled",
                                    "type": "incompatibility"
                                }
                            ],
                            "visible": true
                        },
                        "object_cache": {
                            "enabled": false,
                            "issues": [
                                {
                                    "context": {
                                        "blog_url": "https://blog.cloudlinux.com/",
                                        "supported_handlers": "php-fpm, lsapi"
                                    },
                                    "description": "Website uses unsupported PHP handler. Currently supported handler(s): %(supported_handlers)s.",
                                    "fix_tip": "Please, set or ask your system administrator to set one of the supported PHP handlers for the domain: %(supported_handlers)s. Or keep watching our blog: %(blog_url)s for supported handlers list updates.",
                                    "header": "Unsupported PHP handler",
                                    "type": "incompatibility"
                                }
                            ],
                            "visible": true
                        }
                    },
                    "path": "wordpress",
                    "version": "6.2"
                }
            ]
        },
        {
            "domains": [
                "sub.user0.com"
            ],
            "php_handler": "fastcgi",
            "php_version": "plesk-php73-fastcgi",
            "wps": []
        }
    ],
    "max_cache_memory": "64mb",
    "result": "success",
    "subscription": {
        "object_cache": "no"
    },
    "timestamp": 1681200081.765476,
    "upgrade_url": null,
    "used_memory": null,
    "visible_features": {
        "accelerate_wp": [
            "accelerate_wp"
        ],
        "accelerate_wp_premium": [
            "object_cache"
        ]
    }
}

# Configure redis extension for alt-php

Object cache optimization feature requires several php extensions to be enabled, so there is a script /usr/share/cloudlinux/wpos/enable_redis_for_alt_php.py which does configuration of required modules: redis, igbinary, json.

By default, it modifies global php.ini and enables required extensions there.

Starting from accelerate-wp >= 1.6-7 - to prevent this script of modifying global php.ini - create marker file: /var/clwpos/admin/do_not_modify_global_php.flag. In that case, additional custom php ini with required php extension will be created and global php.ini remains unmodified.

# Billing Integration (upsell automation for premium features)

The premium features of AccelerateWP are intended to generate revenue for CloudLinux hosting customers by adding high-end performance value to WordPress that meets or exceeds the value of premium WordPress Hosting/Managed WordPress market leaders. AccelerateWP premium features are suggested to hosting end-users (and WordPress administrators) when substantial data supports a significant performance boost will be achived upon activation.

# Setting the upgrade URL

When a premium feature is suggested to the user/admin through our SmartAdvice utility, they will be prompted to upgrade. The upgrade URL is where the user will be sent when they click "upgrade" and this is customizable per server (or fleet). There are 2 common upgrade packaging models that will dictate how this URL is set and you will need to make this decision and configure the upgrade URL before offering AccelerateWP premium. The 2 packaging models are:

1. Include AccelerateWP Premium features in your highest tier hosting plans
2. Offer as an add-on subscription to existing hosting plans

Once you have made this decision, you will need to integrate your billing platform.

# WHMCS billing

If you use WHMCS, AccelerateWP Premium billing integration is quite simple. CloudLinux developed its own WHMCS plugin which provides this out of the box. View our documentation to learn how to install and use the plugin.

# Other billing integration

As AccelerateWP Premium is a feature that works on a subscription basis, we made it possible for hosters to integrate their existing billing systems with our plugin and sell the feature for their users.

When AccelerateWP Premium is enabled in the admin interface, users get a proposal to upgrade their subscription.

When a user upgrades the subscription to the plan with AccelerateWP support, billing must execute the following command on the server:

cloudlinux-awp-admin set-suite --suites=accelerate_wp_premium --allowed --source=BILLING_OVERRIDE --users=<username>

This command makes two things:

• allow the user to install the plugin, bypassing the upgrade window;
• reports premium as being used to CLN, starting the billing cycle for the hoster.

When the user terminates or downgrades the plan, the following command must be executed by the billing system:

cloudlinux-awp-admin set-suite --suites=accelerate_wp_premium --default --source=BILLING_OVERRIDE --users=<username>

# Setup upgrade URL for AccelerateWP Premium

The upgrade window can be customized with a link to the plan upgrade page, which can be set using the CLI command:

cloudlinux-awp-admin set-options --upgrade-url https://plan.upgrade/splash

AccelerateWP automatically appends GET parameters when the link is displayed.

https://plan.upgrade/splash/?m=acceleratewp&action=provisioning&username=democom&domain=demo.com&server_ip=10.51.0.10

Parameters can be used to determine the billing account of the user in order to display the proper page. WHMCS plugin already has an automatic redirect to the upgrade page, there is only needed to set upgrade-url to the root of your WHMCS instance.

cloudlinux-awp-admin set-options --upgrade-url https://whmcs.mydomain.zone/

Upgrade URL is opened in a modal browser window and will be automatically closed when AccelerateWP receives a callback about the successful upgrade.

The callback is already implemented in the WHMCS plugin, but if you are using some other billing, you should add the following code on the page which appears when a user successfully upgrades the subscription.

<script>
if(window.opener && !window.opener.closed) {
    window.opener.postMessage('PAYMENT_SUCCESS', '*');
}
</script>

In order to remove the link, just set the upgrade URL to the empty one.

cloudlinux-awp-admin set-options --upgrade-url ''

# Disable AccelerateWP Premium

If you would like to stop using AccelerateWP Premium, click on the manage link and remove the Premium Features checkbox. AccelerateWP will be still available for your users.

# Disable AccelerateWP

If you would like to stop using AccelerateWP completely, toggle the AccelerateWP back. Both AccelerateWP and AccelerateWP Premium will be turned off.

This operation will:

• disable the AccelerateWP tab in the users' control panel interface
• disable all AccelerateWP optimization suites
• deactivate all optimization features for all users

This operation will NOT:

• cancel the subscription made by the user in WHMCS or other billing. The user's subscription stays alive and the user will still be charged in the billing system unless the hoster manually makes a refund

# Logs

The main AccelerateWP log is located at

• /var/log/clwpos/main.log

In case AccelerateWP Premium is active, the auxiliary monitoring daemon clwpos_monitoring is also activated. Its log is located at

• /var/log/clwpos/daemon.log

# FAQ

# With which panel can I use AccelerateWP?

AccelerateWP is compatible with cPanel, Plesk, and DirectAdmin, and it also supports custom control panel integration.

# Is it possible to use AccelerateWP on a non-control panel server?

Yes, if a custom integration mechanism is used: custom control panel integration.

# Do you plan to enable support of the Nginx server?

This is a part of our very long-term plans, thus not expected in the nearest future.

# How will it help my customers?

AccelerateWP is a complex solution to help your customers increase their WordPress site performance. AccelerateWP brings number of optimization features, like object caching, css and js preprocessing and website preloading.

# How could I monitor Redis instances while using the AccelerateWP Premium suite?

The Redis process is started for a user after activating the AccelerateWP Premium Object Caching feature for at least one WordPress site. It is killed after AccelerateWP Premium Object Caching has been deactivated for all user's websites.

Look through the processes list to check the Redis status for a particular user:

 ps aux | grep redis  

 awpuser  2662517  0.0  0.5 101096  8512 ?        Sl   15:33   0:00 /opt/alt/redis/bin/redis-server unixsocket:/home/awpuser/.clwpos/redis.sock

In case if AccelerateWP Premium is active, the auxiliary monitoring daemon clwpos_monitoring is also activated. It checks Redis instances each 5 minutes, starts new instances, restart failed ones and kills the “garbage” instances if needed. Check daemon status using service clwpos_monitoring status and its main log: /var/log/clwpos/daemon.log.

# My users are complaining that their features are not installed automatically after a subscription upgrade

This can be caused by several reasons. Either your customer's website was detected to be malfunctioning or there was an issue with the environment when the feature was installed (e.g. bad internet connectivity with the WordPress market).

First, try to enable the feature manually using the AccelerateWP interface. Most likely you will find a human-readable error message there.

Next, you can try to dive into /var/log/clwpos/daemon.log and find the reason why the enable command failed. Here is an example of a successful feature installation for reference:

2023-02-14 11:01:14,696: (clwpos.daemon_base) [INFO] Running cloudlinux-awp-user enable --feature object_cache --domain wpujj.com --wp-path
2023-02-14 11:01:15,081: (clwpos.daemon_base) [INFO] Command succeded with output:
`CompletedProcess(args=['/bin/cagefs_enter.proxied', 'cloudlinux-awp-user', 'enable', '--feature', 'object_cache', '--domain', 'wpujj.com', '--wp-path', ''], returncode=0, 
stdout='{\n "context": {\n "domain": "wpujj.com",\n "feature": "object_cache"\n  },\n  "result": "success",\n "timestamp": 1676372475.044419,\n \n}\n', stderr='')`
2023-02-14 11:01:15,086: (clwpos.daemon_base) [INFO] background process finished: pid=415368

Also, some useful notes may be present in the user's log located at /home/<username>/.clwpos/main.log.

If the issue persists, or you cannot resolve it yourself, contact CloudLinux support and attach /var/log/clwpos/daemon.log and /home/<username>/.clwpos/main.log for further investigation.

# Troubleshooting

# End-users of AccelerateWP Premium feature encounter Redis extension is not installed for selected php version

In order to make use of the AccelerateWP Premium Object Caching feature, the loaded Redis extension is required for the end-user's website. End-users will not be able to activate the Object Caching feature until the Redis extension configuration is incomplete.

Corresponding incompatibility warning will be displayed in the control panel's User interface:

The Redis extensions are configured for all installed and supported PHP versions automatically:

• right after the AccelerateWP Premium suite is enabled
• by cron once a day

or you can trigger the utility manually:

/usr/sbin/enable_redis_for_panel_php

All errors will be displayed in standard output and logged into /var/log/clwpos/main.log.

Ensuring the EA-PHP Redis extension is configured correctly

1. Check Redis extension package is installed by running the following command

   rpm -q ea-phpXY-php-redis
   

   Install the corresponding extension if it is not present:

   yum install ea-phpXY-php-redis
   

   Consider the example for checking out and installing the Redis extension for ea-php74:

   rpm -q ea-php74-php-redis
   yum install ea-php74-php-redis
   

2. Check Redis ini file is present by running the following command:

   ls /opt/cpanel/ea-phpXY/root/etc/php.d/ | grep 50-redis
   

   Consider the example for checking out Redis extension for ea-php74:

   ls /opt/cpanel/ea-php74/root/etc/php.d/ | grep 50-redis
   

   Try reinstalling the package if ini file is missing.

3. Make sure the Redis module is loaded under a specific user by running the following command:

   su -c "php -m | grep redis" <username>
   

Ensuring the ALT-PHP Redis extension is configured correctly

1. Check if redis.so is present for a particular alt-php version:

   ls /opt/alt/phpXY/usr/lib64/php/modules | grep redis.so
   

   Consider the example for checking alt-php74 redis.so:

   ls /opt/alt/php74/usr/lib64/php/modules | grep redis.so
   redis.so
   

2. If the Redis module is missing:

   a. Install the alt-phpXY-pecl-ext package manually b. Run the Redis configuration script /usr/share/cloudlinux/wpos/enable_redis_for_alt_php.py

   All errors will be displayed in standard output and logged into /var/log/clwpos/main.log.

3. If the Redis module is present for a particular php version, but the incompatibility issue persists, re-check the following:

   a. Make sure the Redis module is loaded under user:

   su -c "php -m | grep redis" <username>
   

   b. Check the required extensions are enabled in php.ini:

   cat /opt/alt/phpXY/etc/php.ini | grep redis.so
   cat /opt/alt/phpXY/etc/php.ini | grep json.so
   cat /opt/alt/phpXY/etc/php.ini | grep igbinary.so
   

   c. Enable missing extensions manually.

# End-users of AccelerateWP encounter PHP-related issues during feature activation

End-users may encounter PHP-related errors while activating the AccelerateWP features.

The general examples of possible reasons are:

• broken PHP binaries
• missing PHP files
• etc.

To check that this issue is caused by PHP itself, call any PHP command, for example:

/opt/cpanel/ea-php80/root/usr/bin/php -i

And make sure that installed ea-php80 packages are not broken using rpm -V <package_name>.

Reinstall broken packages if found.

Consider the example issue (presented at the picture above) with broken mbstring.so for ea-php80:

/opt/cpanel/ea-php80/root/usr/bin/php -i
Segmentation fault (core dumped)  

rpm -V ea-php80 

rpm -V ea-php80-php-mbstring
S.5....T.    /opt/cpanel/ea-php80/root/usr/lib64/php/modules/mbstring.so
......G..  a /usr/lib/.build-id/9c/38ed78a6d401ff6dce059ccea51c95870d98c5  

yum reinstall ea-php80-php-mbstring

# Centralized Monitoring

# Description

Centralized Monitoring is a tool that allows hosting administrators to monitor load for all their servers and users.

Centralized Monitoring allows you to:

• View system metrics for all clients’ end servers
• View the LVE statistics per user for all clients’ end servers
• Enable AccelerateWP Free on all compatible servers

# Installation

1. Make sure you have a CloudLinux OS Shared Pro subscription.
2. Make sure you have installed the latest lve-utils package. You can install or update it with the following commands:
   • installation

   yum install lve-utils
   
   • update

   yum update lve-utils
   
3. Log in to the https://cm.cloudlinux.com/ using CLN credentials (if you are already logged in via CLN, authorization via CM is not necessary, it uses SSO).
4. Activate statistics collection on all your servers via the Centralized Monitoring UI or via the CLN UI. Optionally, activate the AccelerateWP Free* for all of your compatible servers. Additionally, it is possible to activate the AccelerateWP Premium* for all compatible servers.
5. Within couple minutes after the activation, statistics collection and sending to the central server, AccelerateWP Free* and AccelerateWP Premium * will be set up automatically: all required packages and components will be installed. For new, just registered servers, actions can take up to 5 hours.
6. Make sure you have activated statistics collection (see paragraph 4) otherwise you will not be able to set up your servers. For instant set up of a registered server after statistics collection was enabled, run the following commands for all servers:

   rhn_check	
   /usr/share/cloudlinux/cl_plus/manage_clplus enable
   
   Note: If the rhn_check command is not found, run the following command:

   yum install/update rhn-check rhn-setup
   
   AccelerateWP Premium activation support was added in lve-utils-6.5.11-1.
7. After 5 hours (or after the manual setup), check that statistics for all registered servers is collected via https://cm.cloudlinux.com/#/servers. And check that user statistics on the servers is collected via https://cm.cloudlinux.com/#/users.

   Note

   User statistics will be available only for users that were loaded starting from connecting the server to the Centralized Monitoring.

* AccelerateWP Free activation also automatically installs and configures Autotracing on server.

# Centralized Monitoring: mode without session expired

Users can monitor server’s or user’s load for a long time using the mode without session expired.

To turn on the mode without session expired, follow the next steps:

1. Log in to the cln.cloudlinux.com via your account

2. Open the cm.cloudlinux.com in a new browser tab/window (please, use the same browser as in step 1)

3. Use the toggle to turn on/off 10 min auto logout

   

Your session in the cln.cloudlinux.com will expire in 10 min. But your session in the cm.cloudlinux.com will not expire while your browser tab remains open.

# Centralized Monitoring user interface

You can access Centralized Monitoring in your CLN account. Click C-Monitoring in the left menu.

# Servers

This page contains the list of all clients’ end servers. The server appears in the list after finishing Installation. By default, there is a descending sort by CPU usage.

The following values are available for each server:

• Load Avg 15m – average system load for the last 15 min
• CPU Usage – CPU usage for the last 15 min (the number of cores can be found in the hint)
• Memory Usage – free available memory, the second value is the total memory for the last 15 min
• IO read/write – disk read bytes/disk written bytes for the last 15 min

• Idle state – there were no statistics for the server for the last minute.
• N/A state – there were no statistics for the server for the last 30 days. This can happen if a new server was added but statistics sending was not configured.

There is no pagination on the All servers page and all columns can be sorted by absolute value. Use the search tool to operate with the data.

# Servers details

To get the detailed statistics for the server via charts, click a desired server line in the table. All charts are auto-refreshed and there is an ability to select the period for metrics data to be updated for the chart.

# Charts for server metrics

# Visualization of the most popular server states

# Disk space usage

# Open file descriptor/Context switches

# System load 1m , 5m, 15m

# CPU usage (total, system, user, iowait, steal)

# Network traffic usage

# Disk space usage

# Memory usage (total, used, available)

# Time spent doing I/Os

# Disk IOps Completed

# Disk read/write data

# Disk read/write time

# Apache connections (number)/Number of requests per minute/Max connections

# MySQL queries

MySQL queries collector gets number of queries executed on the server per minute. It takes data from the MySQL server variable "Questions". You may manually check variable value by executing query SHOW GLOBAL STATUS LIKE 'Questions';. For more information about MySQL server variables - please, see MySQL documentation.

# The most loaded server users for the last minute

We calculate the user’s load by LVE statistics that we collect on the end server. The idle state for the user means that the LVE statistics were not collected for the last minute for some reason.

In each cell there are current usage/limit values for the basic LVE limits:

• CPU Usage
• Entry Processes
• Physical Memory Usage
• IOPS
• IO Usage
• Number of Processes
• MySQL CPU
• MySQL IO

In the hint, there is a number of faults for each limit. The values in the columns are underlined (it is red if load-to-limit ratio >=90% and it is yellow if load-to-limit ratio >= 50%). For the current implementation, the only sort by the load-to-limit ratio is available. By default, there is a descending sort by the CPU usage column.

When sorting by a column, the lines with the load-to-limit ratio >=90% for this column will have the red background color, and lines with the load-to-limit ratio >=50% for this column will have the yellow background color.

# Users

This page contains all users for the all server of the client and their LVE statistics for the last minute. You can select the number of users on this page and search by user’s data.

The description of this page is the same as The most loaded server users for the last minute of the top 5 loaded users.

User’s metrics data can be sorted by the load-to-limit ratio and by the absolute value.

The absolute value is used to analyse the load produced by unlimited users.

The value of the load-to-limit ratio is convenient to use in the analysis of how many resources the users consume and whether they need to change the limits.

The values like this means that the resource is unlimited and 500.2 MB is the current usage of it.

Metrics data of Idle users is not used in the sorting, so such users always will be at the end of the list. The sorting can be done for only one metric.

# Charts for Users metrics

On the user details page, the admin can find the charts for all LVE limits.

# Alert Manager

Alert Manager allows you to create a server or user alert for selected metrics and email the triggered events.

# Alert Manager page

The Alert Manager page contains a table with the following:

• Alert name - a unique alert name
• Tracking metric - a name of a server/user metric which will trigger the alert notification
• # of servers - number of servers on which the metric will be tracked
  • click to view a list of servers host names
• # of users - number of users for which the metric will be tracked
  • click to view a list of users names
• Value - a condition for the alert rule which will be applied to the tracking metrics
• Email - email to send the triggered events notifications
• Type - a type of the alert rule
• # of triggered events - the number of events from the time, when alert rule was created
  • the event is still firing
• Time of the last trigger - the time of last triggered event, it is the time in your browser time zone
• Actions - click to edit and to delete the alert rule

Color Codes

• Red color means that the event with the condition "more than" is still firing.
• Green color means that the event with the condition "less than" is still firing.

# Creating an alert

To create a new alert, click the Create alert button.

Next, fill out the opened popup.

• Name of alert - a unique alert name
• Alert type - an admin can create a user or a server alert. What is the difference between them?
• Select user/server - admin will see such dropdown depending on a case of alert creating
• Notify me - the condition of the alert trigger
• Duration - how much time the condition should be actual to trigger the notification
• Notify me on email - the email to send notifications

# Editing an alert

An admin can edit any field in the Alert except the Alert type.

# Difference between the server alert and the user alert

The server alert is used to track the state of the whole server, it does not track user state on the server. The server alert tracks the next list of metrics:

1. Context switches
2. System load (1m)
3. System load (5m)
4. System load (15m)
5. CPU Basic (total)
6. CPU Basic (system)
7. CPU Basic (user)
8. CPU Basic (iowait)
9. CPU Basic (steal)
10. Network Traffic Basic (eht0_receive)
11. Network Traffic Basic (eht0_transmit)
12. Network Traffic Basic (ehtN_receive)
13. Network Traffic Basic (ehtN_transmit)
14. Disk Space Used Basic (mountpoint: <0>)
15. Disk Space Used Basic (mountpoint: <1>)
16. Disk Space Used Basic (mountpoint: <N>)
17. Memory Basic (available)
18. Memory Basic (used)
19. Time spent Doing I/Os
20. Disk IOps Writes Completed
21. Disk IOps Reads Completed
22. Disk Read Data
23. Disk Write Data
24. Disk Read Time
25. Disk Write Time
26. Apache connections
27. Number of requests per minute
28. MySQL queries
29. Hardware Temperature (chip<0>)
30. Hardware Temperature (sensor<0>)
31. Hardware Temperature (chip<N>)
32. Hardware Temperature (sensor<N>)
33. Open File Description

During creating a server alert an admin should select the type of metrics as the first step. The list of servers will be collected according to the availability of these metrics on the server.

For example, for now, we do not collect Apache metrics for non-cPanel servers, so you will get only cPanel servers as a list of servers for these metrics.

We're planning to implement support for other panels/web servers in the next releases.

For example, if server state is N/A or idle more than 24 hours, it will not be visible in the list for the alert.

The user alert tracks the next list of LVE metrics:

1. CPU Usage (current usage)
2. CPU Usage (faults)
3. Entry Processes (current usage)
4. Entry Processes (faults)
5. Physical Memory Usage (current usage)
6. Physical Memory Usage (faults)
7. IOPS (current usage)
8. IOPS (faults)
9. IO Usage (current usage)
10. IO Usage (faults)
11. Number of Processes (current usage)
12. Number of Processes (faults)
13. MySQL CPU (current usage)
14. MySQL CPU (faults)
15. MySQL IO (current usage)

For example, if the user state is N/A or idle more than 24 hours, it will not be visible in the list for the alert.

# Cases of alert creating

• Creating a server alert for the selected metrics for one server
• Creating a server alert for the selected metrics for all servers (the default value)

In this two cases, you will not see the dropdown for selecting users because the metrics will track the server state.

• Creating a user alert for one user, so admin can select a server and a user.
• Creating a user alert for all users on several servers/all servers (in this case admin can't select users - all users will be selected automatically)

# What is the Firing state of the alert?

This is the state of an alert that has been active for longer than the configured threshold duration.

# Alert notifications

• Alert name - the link to the alert page
• Firing target - the link to the server details page

# FAQ

# How can I disable collecting and sending statistics on a client’s server?

Run this command:

/usr/share/cloudlinux/cl_plus/manage_clplus disable

# Where can I view all my servers load?

You can find all your servers load in your CM personal account here: https://cm.cloudlinux.com/#/servers or in your CLN personal account here: https://cln.cloudlinux.com/console/cloudlinux/centralized-monitoring.

# Where can I view all my users load?

You can find all your users load in your CM personal account here: https://cm.cloudlinux.com/#/users or in your CLN personal account here: https://cln.cloudlinux.com/console/cloudlinux/centralized-monitoring

# Where can I view a server load details for a period?

Click the desired server in the server list in the UI.

# Where can I view a user load details for the period?

Click the desired user in the user list in the UI.

# How long are statistics stored in the central database?

30 days.

# How can I change the charts period on the details page?

Choose the desired period in the upper right corner or select it directly on the chart.

# I don’t understand how to read the user load chart.

The user load chart contains three lines:

• limit
• current load
• count of faults

Limit and current load are drawing regarding the left vertical axis, the count of faults is drawing regarding the right vertical axis. You can focus on a particular line by clicking a required legend.

# Troubleshooting

# I can't see a server statistics

1. Check that your server is registered by key or by IP license of the CloudLinux+ account, i.e., it should be seen in the list of servers in your CLN account here: https://cln.cloudlinux.com/console/auth/login
2. Check that the following required packages are installed on the end server:

• cl-end-server-tools >= 1.0.7-1
• cl-node-exporter >= 1.1.0-2
• rhn-client-tools
  • CloudLinux OS 6 >= 1.1.15-3.el6.cloudlinux.26
  • CloudLinux OS 7 >= 2.0.2-31.el7.clouldinux
  • CloudLinux OS 8 >= 2.8.16-14.module_el8.1.0+6074+9dc6073e.cloudlinux.2
• lve-stats >= 3.0.7-2
• lve-utils >= 4.2.21-2
• alt-python27-cllib >= 2.1.13-1
• lvemanager >= 6.2.10-1

3. Check that service collecting and sending statistics is running:

service cl_plus_sender status

4. Check that log of the cl_plus_sender service doesn't contain errors:

/var/log/clplus_sender.log

# Where can I view the events log on the client's server?

You can view the events log on the client's server here:

/var/log/clplus_sender.log

# Can I get monitoring metrics from LiteSpeed, Nginx or other (Not Apache) web server?

Starting from end-server-tools-1.0.7, it supports collecting and sending statistics from the Apache and LiteSpeed web servers.

LiteSpeed is supported on cPanel and DirectAdmin control panels.

Each minute the statistics collection daemon checks which web server is started. If LiteSpeed is started, the daemon will collect data from it, otherwise, it checks if Apache is started.

When the daemon detects that the server is changed, it writes the following line into the statistics collection daemon log /var/log/clplus_sender.log:

2020-10-09 17:25:31,462: (CL+_sender_daemon) [INFO] Apache/Litespeed collector: Using Apache

or

2020-10-09 18:13:03,897: (CL+_sender_daemon) [INFO] Apache/Litespeed collector: Using Litespeed

If the daemon can't detect either Apache or LiteSpeed, it writes to the log the following:

2020-10-09 17:33:38,399: (CL+_sender_daemon) [INFO] Apache/Litespeed collector: Apache or Litespeed stopped or absent, collector will not work

The statistics collection daemon reacts to the server changing automatically, no need to restart it.

# Logging data sent to pushgateway to the statistics collection daemon log

Starting from cl-end-server-tools v.1.0.6-1, the statistics collection daemon allows to log data sent to pushgateway to its log /var/log/clplus_sender.log.

To start logging, run the following command:

touch /var/lve/cmt_debug_logging

To stop logging, run the following command:

rm -f /var/lve/cmt_debug_logging

You don't need to restart the daemon after starting/stopping logging. The presence of a control file is evaluated "on the fly".

# Known issues

• MySQL Governor statistics in some cases is collected incorrectly
• Sorting by MySQL Governor statistics ignores idle users
• Sorting from the search result set does not work
• Sorting by ratio for unlimited users works incorrectly

# X-Ray

# Description

X-Ray is a tool developed for website performance monitoring and performance issues detection.

X-Ray can gather and visualize information about top N slowest system functions, external requests, software modules and database queries of the client’s website.

# Known limitations

X-Ray is not compatible with Opcahce JIT optimization. Once X-Ray tracing task is running for the site the Opcache JIT optimization will be disabled until tracing task completed.

# Installation

1. Make sure you have CloudLinux OS Shared Pro subscription (only non-reseller accounts apply)

2. Make sure you have installed LVE Manager version 6.2 or later. You can install or update it with the following commands:

   • installation

   yum install lvemanager
   
   • update

   yum update lvemanager
   

3. X-Ray will be activated on all your servers during 4 hours. You will see the X-Ray tab in the LVE Manager UI.

4. For instant activation, run the following command:

   rhn_check
   

   If the rhn_check command is not found, run the following command:

   yum install rhn-check rhn-setup
   

5. Then install the alt-php-xray package

   • Via user interface

     • Go to the X-Ray tab.
     • Click Install to start installation.

     

   • Via SSH by running the following command:

   yum install lvemanager alt-php-xray
   

6. After installation, use the Start tracing button to create your first tracing task for a slow site.

# X-Ray serverwide mode

With X-Ray v0.6-11 we introduced global X-Ray mode which enables tracing extension for all PHP versions on the servers. This mode allows your customers to override PHP versions in different folders and trace websites located in those folders.

In order to enable this mode, type the following command:

cloudlinux-xray-manager enable-serverwide-mode

In order to get back to default:

cloudlinux-xray-manager disable-serverwide-mode

Enable and disable commands do not stop or remove tracing tasks.

# X-Ray phpinfo mode

With X-Ray v0.6-18 we introduced new X-Ray mode which gathers website php version using information from phpinfo. This mode allows your customers to override PHP versions

In order to enable this mode, type the following command:

touch /opt/cloudlinux/flags/enabled-flags.d/xray-per-domain-php-version-mode.flag

In order to get back to default:

rm -f /opt/cloudlinux/flags/enabled-flags.d/xray-per-domain-php-version-mode.flag

# How to manage X-Ray

X-Ray provides several options for monitoring domain requests speed: Manual Tracing task, X-Ray Autotracing and Continuous tracing.

• Manual Tracing task is a task that you can create for a specific URL to collect server requests. The task will end either after a specified number of requests to the URL or after a specified time (maximum after two days). It is not possible here to automatically email a report but it is possible to export the report in PDF and send to a user.

• Autotracing task is a task that will be created automatically at the end of each day for slow URLs that were found during that day by the PHP Slow Site Analyzer (SSA). Need to be enabled separately, see How to enable X-Ray Autotracing.

• Continuous tracing is a task that initiates daily hourly tracing requests for a specified domain and email a monitoring report. Continuous task can't stop automatically, you need to stop it manually. In fact, continuous task allows to automatically create a tracing task for each new day, with the ability to get a report for the past day.

# Tracing tasks tab

The Tracing tasks tab contains a list of all tracing tasks created both manually and automatically via continuous tasks.

The Created column shows how a task was created – automatically (by continuous task) or manually.

# Continuous tracing tab

yum update lvemanager alt-php-xray

The Continuous tracing tab contains a list of continuous tasks for which tracing tasks will be created automatically for a new day for a specific domain.

# Managing tracing task

# Creating a new tracing task

1. Go to the X-Ray tab
2. Click the Start tracing button to create a new task
3. In the opened popup specify a website URL to trace
4. Click the Run button
5. Tracing will run in the default mode. In the default mode X-Ray traces the first 20 requests for a specified URL

• URL should be a valid URL of the domain which exists on the current hosting server. The URL field supports wildcard matching. To learn more about wildcard matching, click How to use special characters.

• Advanced settings allow you to set an IP address and tracing options: by time or by number of queries.

  

Advanced settings

• Client’s IP: it is an IPv4 address of a machine to trace. For example, if you have a production website that processes requests from different IP addresses and you do not want to add these requests to the tracing task. So, you can set a specific IP address and X-Ray will analyze requests only from this specific IP address. Record for
• Time period: how much time X-Ray collect the requests (2 days max)
• Requests: the amount of requests that X-Ray will collect

After creating, the task appears in the list of tracing tasks.

# Viewing tracing tasks list

Tasks created Manually are simply tracing tasks.

# Tracing status

A tracing task can have the following statuses:

• Running – tracing is in progress
• Stopped – tracing was stopped by administrator
• On hold – the same URL already exists in the lists. Task processing will not start automatically. Administrator should start it manually.
• Completed – period of time is finished or number of requests is reached.

# Collected requests for tracing task

Click to open a list of collected requests.

# Tracing tasks

The slowest request is highlighted.

• Total displays how many requests were collected according to tasks requirements.
• Pending displays how many of collected requests are not visible in the table yet.
• Throttled displays the number of requests during the execution of which the LVE limits were exceeded.
• Slow displays the number of requests lasting more than one second.

There are filters for the request types and the indicator of a filter used now.

If slow requests were not detected during the tracing task, the following is displayed. Here, you can also view all requests.

X-Ray collects the following data for each request:

• Top issues – the slowest items of a request
• Software modules/plugins by execution time (only for WordPress plugins)
• Database queries by execution time
• External requests by execution time
• Other system functions by execution time

# Software modules/plugins

The Software modules/plugins section displays the following data:

• Software type – a type a module/plugin. For now, X-Ray can analyze only WordPress software
• Software module – a name of the WordPress plugin
• Duration – plugin execution time
• Duration (%) – plugin execution time as a percentage of the total duration of the request

# Database queries

The Database queries section displays the following data:

• Query – the executed SQL-query
• File – the file and the line of the executed query and backtrace
• Software module – a WordPress plugin name from which the request was completed. If the request does not belong to any of the WordPress plugin, the name of the function that executed the given request is displayed
• Calls – the number of identical SQL queries
• Duration – execution time as a percentage of the total duration of a request and the function processing time (in brackets)

# External requests

The External requests section displays the following data:

• URL – the URL of the executed request
• File – the file and the line of the executed request and backtrace
• Duration – execution time as a percentage of the total duration of a request and the function processing time (in brackets)

# System functions

The System functions section displays the following data:

• Function – the executed function
• File – the file and the line of the executed request
• Duration – execution time as a percentage of the total duration of a request and the function processing time (in brackets)

# Stopping tracing task

Click to stop the tracing task.

The tracing task status will be changed to Stopped. Data will not be collected anymore but you can see already collected information or continue tracing later by clicking .

# Deleting tracing task

Click to delete the tracing task.

# Managing continuous tasks

# Creating a new continuous task

1. Click the Create continuous tracing button

2. Specify URL in the Domain field and email in the Email for reports field and click the Create button.

3. You can see a new task in the Continuous tracing tab in the X-Ray UI.

4. If you stop a continuous tracing task, a new task for the next 24 hours will not be created. The task for the current day will be finished at midnight and the report will be emailed.

5. If you delete a continuous tracing task, the task for the current day will be finished at midnight and the report will be emailed.

# Viewing continuous tasks list

You can find a list of continuous tracing tasks in the Continuous tracing tab.

You can find automatically created tasks in the Tracing tasks tab marked as Automatically in the Created column.

The statuses for automatically created tasks are the same as for tracing task.

To view detailed info about an automatically created task, click . You will get requests grouped by hour.

Click to a group to open a list of the requests.

The following data is collected for each request:

• Software modules/plugins by execution time (only for WordPress plugins)
• Database queries by execution time
• External requests by execution time
• Other system functions by execution time

# Stopping automatic tracing task

Stopping automatic tracing task (a part of continuous tracing task) affects only the automatic tracing task for the current day. A new task for the next day will be created at the end of the day.

To stop the continuous tracing task completely, see Creating a new continuous task, paragraph 4.

# Deleting automatic tracing task

Deleting automatic tracing task (a part of continuous tracing task) affects only the automatic tracing task for the current day. A new task for the next day will be created at the end of the day.

To delete the continuous tracing task completely, see Creating a new continuous task, paragraph 5.

# Continuous task daily report

1. Users get daily reports on their emails. An example of a report is shown below:

   

2. Click the link in the email to show the detailed report:

   

3. You can view requests grouped by hour:

   

4. You can also view the detailed information about request:

   

# X-Ray Autotracing

X-Ray Autotracing automatically creates tracing tasks for slow URLs that were found during a day by the PHP Slow Site Analyzer (SSA).

yum update alt-php-ssa alt-php-xray --enablerepo=cloudlinux-updates-testing

# How to enable X-Ray Autotracing

To enable X-Ray Autotracing, run the following commands via SSH:

/usr/sbin/cloudlinux-ssa-manager enable-ssa
/usr/sbin/cloudlinux-autotracing enable --all

Check CLI documentation for a description of the /usr/sbin/cloudlinux-autotracing CLI utility.

# Requirements

• CloudLinux OS Shared Pro or CloudLinux OS Solo or CloudLinux OS Admin
• alt-php-ssa > 0.2-1 version
• alt-php-xray > 0.4-1 version
• Enabled PHP SSA on the server

# Autotracing Interface

A new tab for Autotracing tasks was added to the X-Ray UI:

# Autotracing FAQ

Q: Why are the slow URLs in the Slow Site Analyzer report different from those on which the autotracing tasks were created?

A: Because the autotracing decision module uses rules and thresholds different from Slow Site Analyzer, which are configured by the CloudLinux team.

Q: How often autotracing tasks will be generated?

A: Once a day at the same time as a Slow Site Analyzer report.

# X-Ray Smart Advice

Smart advice is a new feature of X-Ray that is designed to find and propose solutions to fix performance issues and speed up the performance of a sites.

yum update alt-php-ssa alt-php-xray lve-utils lvemanager --enablerepo=cloudlinux-updates-testing

# How to enable X-Ray Smart Advice

# Requirements

• CloudLinux OS Shared Pro or CloudLinux OS Solo
• alt-php-xray > 0.5-1 version
• lve-utils > 6.3.2-1 version
• lvemanager > 7.6.1-1 version
• cloudlinux-site-optimization-module > 0.1-1 version

We Recommend:

• Enable X-Ray Autotracing on the server
• Use alt-php-ssa > 0.2-3 version

# How X-Ray Smart Advice works

The main process of looking for advice is X-Ray tracing tasks. The best way for doing this is to enable X-Ray Autotracing. This will allow you to most effectively find Smart Advice for sites that have performance issues without your manual participation. You can find information on how to enable X-Ray Autotracing here. On the other hand, you can create tracing tasks manually or use continuous X-Ray but we suggest you use X-Ray Autotracing for this purpose.

While the tracing task is running, X-Ray will look for places where advice can be applied. New advice will be displayed on the Smart Advice tab.

After the X-Ray finds advice you will see new advice in the Review status on the Smart Advice tab. Then you may use the Details button to see which URLs were found by X-Ray that will be speed up by that advice and use Quick Action to enable advice for a site.

Example of details:

After you apply the advice by using Quick Action, the status will change to the Applied.

If a long time has passed since the last time the advice was updated for a site, it will be moved to the Outdated status.

If the process of applying advice fails you will see an error log with a detailed error, you may try to fix it manually and try again or contact our support team for help.

Example when an error appears during advice applying:

# Smart Advice FAQ

Q: Why I can't see new advice on the Smart Advice tab?

A: For the generating of advice, it is necessary to run X-Ray tracing tasks, the best way to do it without manual interaction is to use X-Ray Autoracing. You can find more information on how to enable X-Ray Autotracing here.

# Smart Advice CLI commands

CLI commands for managing feature advices

• cl-smart-advice - for managing advices;

Starting from alt-php-xray-0.5-25 Smart Advice CLI utilities provide CLI versioning which is defined via --api-version option.

cl-smart-advice --api-version <api_version> <command>

supported commands for --api-version=1:

• list - shows list of all advices;
• apply - applies specific advice;
• rollback - rollbacks specific advice;

# Advices list

--api-version=1

cl-smart-advice --api-version=<api_version> list

For each advice in the list the CLI command returns the following information:

• metadata, which includes information about username, domain and website for which the advice is issued
• advice information:
  • its identifier id (id, that should be used in apply and rollback commands)
  • its type (optimization feature identifier)
  • its status - current status: review or applied
  • module_name - name of optimization feature
  • is_premium - if advice is for optimization feature from AccelerateWP Premium suite
  • subscription - info about optimization suite subscription (only if advice requires subscription)
  • description and detailed_description - human-readable descriptions of advice
  • other internal informational fields
• result - result of command: it may have success or error details

Successful output example of cl-smart-advice --api-version=1 list:

{
  "data": [
    {
      "created_at": "2023-04-11T07:33:48.191870+00:00",
      "updated_at": "2023-04-11T07:33:48.191870+00:00",
      "metadata": {
        "username": "user16",
        "domain": "user16.com",
        "website": "/wordpress"
      },
      "advice": {
        "id": 23484,
        "type": "OBJECT_CACHE",
        "status": "review",
        "description": "Turn on Object Caching",
        "is_premium": true,
        "module_name": "object_cache",
        "subscription": {
          "status": "no",
          "upgrade_url": null
        },
        "total_stages": 0,
        "completed_stages": 0,
        "detailed_description": "To improve site performance, enable the Object Caching We recommend applying the advice if you see it frequen
tly for the most valuable URLs of your site."
      }
    },
    {
      "created_at": "2023-04-11T07:33:48.297784+00:00",
      "updated_at": "2023-04-11T08:51:42.362117+00:00",
      "metadata": {
        "username": "user16",
        "domain": "user16.com",
        "website": "/wordpress"
      },
      "advice": {
        "id": 23485,
        "type": "SITE_OPTIMIZATION",
        "status": "applied",
        "description": "Turn on AccelerateWP feature",
        "is_premium": false,
        "module_name": "accelerate_wp",
        "total_stages": 0,
        "completed_stages": 0,
        "detailed_description": "To improve site performance, enable the AccelerateWP optimization feature. We recommend applying the advice if you see it frequently for the most valuable URLs of your site."
      }
    }
  ],
  "result": "success",
  "timestamp": 1681203110
}

Failed output example of cl-smart-advice --api-version=1 list:

{"result": "Malformed API response"}

# Apply advice

--api-version=1

cl-smart-advice --api-version=<api_version> apply --advice_id=<id_of_advice> [ --accept_license_terms ] [ --ignore-errors ]

--accept_license_terms - accept license terms on applying CDN type advice; --ignore-errors - ignore WordPress site web-checks after enabling optimization features;

advice_id from cl-smart-advice --api-version=<api_version> list output

Successful output example of cl-smart-advice --api-version=1 apply --advice_id=12345:

{
    "feature": {
        "enabled": true
    },
    "result": "success",
    "timestamp": 1690806590.0494235
}

• feature: status of optimization to be applied via advice
  • enabled: true or false value meaning feature is enabled or not
• result: result of command: it may have success or error details

Failed output example of cl-smart-advice --api-version=1 apply --advice_id=12345:

{"result": "Malformed API response"}

# Rollback advice

--api-version=1

cl-smart-advice --api-version=<api_version> rollback --advice_id=<id_of_advice>

advice_id from cl-smart-advice --api-version=<api_version> list output

Successful output example of cl-smart-advice --api-version=1 rollback --advice_id=12345:

{
    "feature": {
        "enabled": false,
        "visible": true
    },
    "result": "success",
    "timestamp": 1690806844.9735684
}

• feature: status of optimization to be applied via advice
  • enabled: true or false value meaning feature is enabled or not
  • visible: true or false value meaning feature is visible or not
• result: result of command: it may have success or error details

Failed output example of cl-smart-advice --api-version=1 rollback --advice_id=12345:

{"result": "Malformed API response"}

# Advanced performance analytics

By enabling this feature, X-Ray will add JavaScript profiling code to each WordPress site during the tracing process. This will allow X-Ray to provide highly detailed insights into each website’s performance (greatly enhancing the quality and accuracy of SmartAdvice). The performance metrics that will be collected include TTFB (Time To First Byte), Total Blocking Time, First Contentful Paint, and more. The profiling code does not collect any user or visitor data nor sensitive data of any kind. The sole purpose of this profiling code is to gather performance-related metrics to better optimize the website.

# How to enable/disable via UI

You can manage the setting in several interfaces:

X-Ray settings:

AccelerateWP settings:

# How to enable/disable via CLI

cloudlinux-xray-manager advanced-metrics --enable

cloudlinux-xray-manager advanced-metrics --disable

# How it works

To start advanced performance monitoring, you can enable tracing tasks that involve adding a JavaScript snippet to the bottom of your WordPress page. This snippet facilitates performance monitoring and allows X-Ray to gather valuable insights.

Once tracing tasks are enabled, the JavaScript snippet will periodically send POST requests to our secure analytics service.

These requests capture anonymous data about page load time and resources.

# End-user X-Ray plugin

yum update lvemanager alt-php-xray

# How to enable/disable the end-user X-Ray plugin

You can hide or show the end-user X-Ray plugin icon by ticking or unticking the proper checkbox in the LVE Manager.

Go to LVE Manager → Options Tab → User interface settings.

# How to manage the end-user X-Ray plugin

The web interface of the end-user X-Ray plugin is almost the same as the X-Ray administrator interface.

But there are some differences and they are described further.

• End-users can create tasks only for their domains from the drop-down list:
• To specify URL or wildcard, end-users should use the input field next to the domain:

You can read about all other basic interface elements and managing tracing tasks in the Managing tracing task section.

# End-user X-Ray plugin limitations

• The end-user X-Ray plugin does not support creating continuous tasks.

• The end-user has a limit of tracing tasks running at a time. Before starting the next task, the end-user should wait for the completion of the previous ones or forcefully stop the running ones. Otherwise, the user will get the next error:

  

  Note

  The current limit is one tracing task per user.

• The administrator and the end-user can’t run the tracing task for the same Domain/URL at the same time. Once, the administrator started a specific tracing task, the end-user will not be able to duplicate it. And the same is true for the administrators – they will just see the running task for the specific domain and see the notification that they're trying to create a tracing task with a duplicated URL.

• If continuous tracing is enabled for the domain, the end-user will not be able to create a new task for this domain because the same rule works - it will be a duplicate of the existing tracing tasks. The next warning will appear:

  

  To solve this, the existing running tasks for the same Domain/URL should be stopped or completed. You can find more details about this in the FAQ.

• If a user's tracing task was created for a domain which is using the FPM handler there's an additional limitation. To avoid frequent reloads of the particular FPM service, Start tracing , Stop tracing or Continue tracing action would be blocked in case if the latest reload of a corresponding FPM service was done less than 1 minute ago.
  If a user gets such an error message - it means that 1 reload in 1 minute for a particular FPM service has been already done. Just try performing the same operation once again in a while.

# X-Ray automated throttling detection

The X-Ray automated throttling detection system checks if the account exceeds LVE limits by CPU or by IO/IOPS during the HTTP request execution. Requests with exceeded LVE limits are indicated in both X-Ray Administrator and X-Ray User plugins.

If CPU limiting was detected for a particular request, it is indicated in the X-Ray UI that the system itself has slowed down the request processing due to CPU throttling and this is apparently not a performance issue in the PHP code.

If limiting by IO and IOPS in total was detected for a particular request, it is indicated in the X-Ray UI in the same manner, except for the cause of slowing down the request -- IO throttling.

The case of both limiting for the request is also possible.

Requests with exceeded LVE limits are also marked in the request detailed view.

Requests with exceeded LVE limits are marked in the PDF report as well.

# X-Ray client

X-Ray client is a PHP extension named xray.so. It analyzes the processing time of the entire request and its parts and then sends the data to the X-Ray agent.

# List of supported PHP versions

The list of currently supported PHP versions:

# Functions that X-Ray client can hook

# Database queries

• Functions from the MySQL extension:
  • mysql_query
  • mysql_db_query
  • mysql_unbuffered_query
• Functions from the MySQLi extension:
  • mysqli_query
  • mysqli::query
  • mysqli_multi_query
  • mysqli::multi_query
  • mysqli_real_query
  • mysqli::real_query
• Functions from the PDO extension:
  • PDO::exec
  • PDO::query
  • PDOStatement::execute

# External requests

• Function curl_exec

# System PHP functions

It may be any PHP system function which can be related to a PHP engine or other PHP extension, for example fopen() or json_encode(). A list of these functions can be found here.

# Configuration Options

Syntax: xray.enabled=On/Off

Default: On

Changeable: PHP_INI_SYSTEM

Description: Enable or disable X-Ray extension from php.ini

Syntax: xray.database_queries=[number]

Default: 20

Changeable: PHP_INI_SYSTEM

Description: The number of the slowest SQL queries which will be sent to the X-Ray agent. The min value is 0 and the max value is 100. If the variable value is more, the default value will be used.

Syntax: xray.external_requests=[number]

Default: 20

Changeable: PHP_INI_SYSTEM

Description: The number of the slowest external requests (the curl_exec function) which will be sent to the X-Ray agent. The min value is 0 and the max value is 100. If the variable value is more, the default value will be used.

Syntax: xray.system_functions=[number]

Default: 20

Changeable: PHP_INI_SYSTEM

Description: The number of the slowest system functions which will be sent to the X-Ray agent. The min value is 0 and the max value is 100. If the variable value is more, the default value will be used.

Syntax: xray.backtrace_depth=[number]

Default: 10

Changeable: PHP_INI_SYSTEM

Description: The backtrace depth to the main() function which will be sent to the X-Ray agent. The min value is 0 and the max value is 20. If the variable value is more, the default value will be used.

Syntax: xray.processor=[processor_name]

Default: xray

Changeable: PHP_INI_SYSTEM

Description: Tells the X-Ray client which processor to use. The new processors may be added in the future. The default processor is xray which means to send data to the X-Ray agent.

Syntax: xray.tasks=host:uri:ip:id

Default: no value

Changeable: PHP_INI_SYSTEM

Description: The current tracing tasks for the given PHP request. This directive is added automatically by the X-Ray manager when creating a task. It is not allowed to edit manually, as X-Ray may stop working.

Syntax: xray.to_file=On/Off

Default: Off

Changeable: PHP_INI_SYSTEM

Description: Only for debug purposes. Writes to a file data which is sent to the processor.

Syntax: xray.debug=On/Off

Default: Off

Changeable: PHP_INI_SYSTEM

Description: Only for debug purposes. Enables debug output during request processing. In the On mode can slow down the domain.

Syntax: xray.debug_file=[path_to_file]

Default: /tmp/xray-debug.log

Changeable: PHP_INI_SYSTEM

Description: Only for debug purposes. Specifies a file for logging debug information.

# X-Ray agent

This is a service that receives data from the X-Ray client and sends it to the remote storage.

# Managing X-Ray service

The X-Ray agent is managed by the service utility.

• To start the X-Ray agent, run the following command:

  service xray-agent start
  

• To stop the X-Ray agent, run the following command:

  service xray-agent stop
  

• To restart the X-Ray agent, run the following command:

  service xray-agent restart
  

# FAQ

# Does X-Ray affect website performance?

X-Ray affects website performance. Our tests show 5-10 % overhead from a website loading time with X-Ray tracing enabled. X-Ray allows you to find website performance issues and should not be enabled permanently. If your website is very slow, you can enable X-Ray to find the cause and then disable it.

# My customers override php versions in different folders and X-Ray does not trace those websites, what should I do?

You should turn on the X-Ray serverwide mode or the X-Ray phpinfo mode.

# What should I do if I see the warning "Task is duplicated by URL"?

This warning means that you already have a task to trace this URL in the list of your tracing tasks. If you see this warning, a new task can be created only with the On hold status and you will be able to run it only when the previous task with the same URL will be completed.

Note that the URL field supports wildcard matching and you can have a case when X-Ray is tracing the URL=domain.com/* and you are trying to create a new task with URL=domain.com/xray.php. In this case, you will see that warning because the * URLs array includes xray.php.

# I started a tracing task and made requests to URL but did not see any results in the UI. What should I do?

1. X-Ray may not send data if a site uses a caching plugin, as the caching plugin is outputting HTML, thus there are no PHP scripts to examine. We encountered such issues with sites that use LSCache and WP Super Cache plugins. Check that your site does not use caching plugins. If so, disable it while tracing a site to get information from X-Ray. Moreover, it can also be because of caching on server side, for example NGINX Cache. Or when using CDN because requests are processed from another host. In such cases, during tracing, caching must also be disabled.

2. If you set a client’s IP when creating the tracing task, check that your requests come to the server with this IP via phpinfo (since there may be NAT between your local machine and the server).

   

3. Check that xray extension is enabled for the domain. To do so, go to the phpinfo() page and make a request. In the phpinfo output try to find the following section:

   

If you cannot see that section, try to restart PHP processes for that user (the simplest way is to restart Apache) and check that you can see the xray extension.

4. If you can see the xray extension in the phpinfo, check that X-Ray agent service is running with the service xray-agent status command. If it is not running, start it with the service xray-agent start command.

5. If, after checking the previous items, the issue persists, contact our support team.

# What to do if X-Ray is not found in the phpinfo() page?

If you managed to create a tracing task, this means that the xray.ini file was created in a system. Therefore, there may be two reasons why it did not appear in the phpinfo page of the domain.

1. PHP process wasn't reloaded after adding the xray.ini. To solve this, you should restart the Apache or fpm service for the domain on which the tracing was started. At the moment, this is done automatically by the X-Ray manager after creating the task.

2. Your domain uses a PHP version different from the one which was detected by the X-Ray manager. To solve this, check the scan dir for additional ini files for your domain.

   

   Then check the ini_location that was passed to the X-Ray manager by running the following command:

   cat /usr/share/alt-php-xray/manager.log | grep ini_location
   

   Find your tracing task in the output and check that the xray.ini exists in this directory, also check that the ini path is the same in the phpinfo page output and in the ini_location directive for your tracing task. If they are the same, you should reload your PHP. If they are different that means that the X-Ray manager could not correctly determine the PHP version your domain uses. In this case, contact our support team at https://cloudlinux.zendesk.com/hc/requests/new.

# I use LiteSpeed, X-Ray is enabled and it is shown in the phpinfo() page but does not collect data when sending requests to a site. What to do?

Check for the CacheLookup on option in the htaccess file for your domain. If the option is there, LiteSpeed processes requests bypassing the PHP X-Ray extension. In this case, to get tracing information, you should remove the CacheLookup on option.

# What is the proper format for the URL?

All of the examples below are correct:

• http://domain.com
• http://domain.com/
• https://domain.com
• https://domain.com/

You can use any of them with a prefix www. and it is also correct.

# What packages are required for X-Ray?

Required packages:

• lvemanager >= 6.2.10-1
• alt-php-xray >= 0.2-1

$$$$$$$$$$$$$4