New Hestia Installation Fails Loader I/O Stress Tests (Help)

I have a server with 90 high traffic wordpress sites.
In order to get rid of the huge CPU usage and the loading delay, you need to either edit the php-fpm template or make sure you use the fastcgi-cache.
By default, the hestia PHP template is configured for normal web hosting, with PHP-FPM’s PM (process manager) set to ondemand. With this setting, processes spawn for each page request and there will be a slight delay and a cpu usage due to the process spawning overhead. This is normal for basic webhosting with little traffic, but for high traffic websites you will need to set the PM either to dynamic or static.
I won’t cover the static setting cause with this you need to know for sure what traffic to expect and what memory you need to allocate.
With the dynamic setting, the child processes are set dynamically based on the following directives: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers .
Using this setting, the processes are already created waiting for requests and won’t have that huge overhead, so there is no CPU and memory spike when accepting a new request.
To create a new php-fpm template, go to /usr/local/hestia/data/templates/web/php-fpm and create a new file based on an existing template, and change the settings. You will need to adjust the settings based on your server hardware.
Note that the dynamic setting will allocate processes and memory for each website, even if there are no requests.
I use a custom template where I share a pool with all the sites of the user, insead of using the pool for each website as default. This gives the fexibility to allocate resources by user, but you need to further config the hestia packages and the nginx templates (/usr/local/hestia/data/templates/web/nginx/php-fpm).
I don’t use apache since wordpress works fine with nginx only and I don’t need the .htaccess. With apache will be a little more complicated to configure and there is extra overhead.
TLDR; To reduce the request initial delay and CPU spike, either make sure the fastcgi-cache works fine or set PHP-FPM’s PM (process manager) to dynamic .

3 Likes

Thanks for this tip. I will definitely give it a try. Any chance you share the changes you’ve made to the templates?

1 Like

First you should add a new php-fpm pool config, and be warned that this pool will be shared with multiple websites, you should use this pool only for one user. I named the user wordpress, and so the pool.
The config in my case is `[wordpress]
listen = /run/php/php7.4-fpm-wordpress.sock

listen.owner = wordpress
listen.group = www-data
listen.mode = 0660

user = wordpress
group = wordpress

pm = dynamic
pm.max_children = 8192
;pm.start_servers = min_spare_servers + (max_spare_servers - min_spare_servers) / 2
pm.start_servers = 128;
pm.min_spare_servers = 128
pm.max_spare_servers = 256

pm.max_requests = 20000
pm.process_idle_timeout = 5s
pm.status_path = /status

request_terminate_timeout = 120s

slowlog = /var/log/php7.4-fpm-wordpress-slow.log

php_admin_value[upload_tmp_dir] = /home/wordpress/tmp
php_admin_value[session.save_path] = /home/wordpress/tmp
php_admin_value[max_input_vars] = 10000

env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /home/wordpress/tmp
env[TMPDIR] = /home/wordpress/tmp
env[TEMP] = /home/wordpress/tmp`

You should add it to /etc/php/7.4/fpm/pool.d and name it wordpress.conf .
For it to work, next we need to create a new php-fpm template on /usr/local/hestia/data/templates/web/php-fpm. Name it PHP-7_4-custom.tpl and leave it empty, we only need it for the control panel, and we will create a new nginx template to use our shared pool.
For the new nginx template just copy the /usr/local/hestia/data/templates/web/nginx/php-fpm/wordpress.tpl/stpl files into new ones, wordpress-custom.tpl/stpl.
Then only change fastcgi_pass %backend_lsnr%; with fastcgi_pass unix:/run/php/php7.4-fpm-wordpress.sock;
It can be automated with a hook script that replace the wordpress keyword with %user% in case you need it for multiple users and the wordpress template can be further improved to include caching, custom headers and brute-force limits.

3 Likes

Should be custom-PHP-7_4.tpl so you can create a own pool for each websites if needed

Thanks @caii @eris !!!

Hi to all,

Did anyone, specially @deewinc or @gahia, could you get HestiaCP configuration close to CyberPanel results?

If so could you share confirgurations tempalte and tips.

Thanks a lot!

I confirm that I had done this optimization in the past (set to static for a single site server and configure accordingly) and I saw improvements. Though I don’t have any metrics to share :frowning:

After rigorous tests, it’s important to note that the issue is beyond the control panels but the web server itself.

In this case, CyberPanel is designed to work with OLS/LiteSpeed and every configuration is baked for that web server. Other than that, Nginx just can’t come close to LiteSpeed when it comes to WordPress and Magento.

As I shared earlier, I have tried different panels to optimize Nginx to see if it can stack up against Litespeed but it just couldn’t match up for WordPress. This has to do with the way LiteSpeed caches and handles PHP requests. It’s just freaking fast than Fast-CGI on Nginx.

Also note that, any control panel that support LiteSpeed will give you the same performance with CyberPanel.

So it’s not an issue to do with HestiaCP as I earlier captioned but how the individual web servers are designed. Again as I mentioned earlier, optimizing Nginx/Apache to come close to the performance of LiteSpeed is a tedious undertaking.

As @eris already wrote above → closed.

1 Like