Performance Guidelines
Our team is constantly working on improving performance, so we are pushing changes rapidly with tag "Experimental".
We are working on improving performance both on single DC installations and cross DC.
The purpose of this article is to illustrate the most common issues and their solutions.
Case: High CPU for PHP-FPM processes
This is usually caused by bots trying to scan MAC addresses from the Stalker API or Xcode API.
Possible Solution 1:
Since the PHP framework proved to be quite heavy, in version v1.0.95 we have pushed an option to replace PHP-FPM with RoadRunner App Server for the LB part.
You can find the setting in Server edit page, it requires Reconfigure.
RoadRunner has proved to lower a lot the CPU usage of the API.
Option "RoadRunner+FPM Preload" should bring maximum improvement to performance by the time this article was written.
Streaming content will still continue to be served from PHP-FPM for maximum stability.
Possible Solution 2:
It is a good idea to enable the AutoBlock Addon (see https://billing.1-stream.com/whmcs/index.php/knowledgebase/11/Autoblock-Addon.html).
The "default" rule of AutoBlock can capture scanner.
Starting of version v1.0.3 of AutoBlock we have presented a rule "flood" for flood detection with configurable options.
You can enable the IP Tables usage so that blocked IPs will be added to the firewall.
Possible Solution 3:
In case your system is meant to have big traffic, it is good to consider using Entry Point to balance the traffic (see https://billing.1-stream.com/whmcs/index.php/knowledgebase/10/Proxy-Addon.html).
Case: High memory usage in LB with low memory
Possible Solution 1:
In case your LB is limited of RAM, you can mount the Streams folder on Disk (instead of RAM which is default).
This will free RAM, but do monitor for performance drawback due to IO.
Case: Slowness of serving M3Us/API from server in a different DC from the Main (DB) Server.
In case the connection between Server and DB is slow, you may notice general slowness.
Possible Solution 1:
We do provide Redis cache instance on every LB to deal with cross DC issues.
This can be resolved by enabling "Persistent Cache" of Streams/Series/Bouquets.
This will store the data in Redis instance on the Server itself and avoid calling DB.
Depending on how much data you have, the first iteration of the cache worker may be slower. Afterwards, changed data is refreshed on 2min.
Possible solution 2:
You can enable the Async generation of M3U (Setting->Streaming->).
It will generate the M3U for a line on the first request and keep cached file for a few hours.
Case: Having big M3U that crashes players
In case you have big M3Us, you may have noticed that our files are bigger than XC.
Possible Solution 1:
By default we use signed tokens to prevent bruteforce, but if anyway you have enabled the XC API support, you can enable generating XC URLs in the M3U. This will lower the size of the playlist.
If you experience any issues not listed here, do not hesitate to contact our Support via Ticket.
