GRAV and HESTIA perfomance setup with NGINX and PHP-FPM 8.0

Ubi · November 24, 2021, 9:17am

Hi community,

I am facing a courious issue with HESTIA.

We are worrking on a GRAV site with aprox 7k pages and two languages. The current dev server is a pure DEBIAN 10 with APACHE and mod php 7.3 (without any panel or HESTIA). On this development server (with very stadard settings for php and apache) we have no perfomances issues at all. wIth PECL YAML and APCu module installed it’s really a rocket considering the number of parsed pages.

We are now trying to test the staging server before to go live and I suggested the client to use HESTIA. Client agrees and he prefers NGINX only and PHP-FPM 8.0 on DEBIAN 11. So this is the HESTIA base setup for this staging server.

We installed PECL YAML and APCu and we are using the default GRAV template provided by HESTIA.
Everything is working fine, no errors or issues on any log (error logs, installation logs, system logs, etc)
Grav is up and running and all the checks are fine.

BUT PERFOMANCES are a way far from the development server with basic APACHE and PHP 7.3.

Both servers are almost identical from HW viewpoint (8 GB RAM, SSDs, 2 CPUs, High bandwith, etc).

Since are days we are struggling to understand the reason for these low perfomances within HESTIA, is there anyone with some tips for GRAV perfomances with HESTIA and/or some advice to point us to some missing configuration we are not aware?

Thanks!

Ubi · November 24, 2021, 11:38am

UPDATE

I’ve reinstalled the same DEVELOPMENT server with HESTIA from scratch (to double check). Same server, but still perfomances very low with HESTIA. Maybe some NGINX or PHP setting to adjust, beside the one’s already changed like max memory limit for php or total workers for NGINX.

eris · November 24, 2021, 11:47am

What is the exact issue performance with almost 0 traffic or with some load?

github.com

hestiacp/hestiacp/blob/main/install/deb/php-fpm/multiphp.tpl

; origin-src: deb/php-fpm/multiphp.tpl

[%domain%]
listen = /run/php/php%backend_version%-fpm-%domain%.sock
listen.owner = %user%
listen.group = www-data
listen.mode = 0660

user = %user%
group = %user%

pm = ondemand
pm.max_children = 8
pm.max_requests = 4000
pm.process_idle_timeout = 10s
pm.status_path = /status

php_admin_value[upload_tmp_dir] = /home/%user%/tmp
php_admin_value[session.save_path] = /home/%user%/tmp
php_admin_value[open_basedir] = /home/%user%/.composer:/home/%user%/web/%domain%/public_html:/home/%user%/web/%domain%/private:/home/%user%/web/%domain%/public_shtml:/home/%user%/tmp:/tmp:/var/www/html:/bin:/usr/bin:/usr/local/bin:/usr/share:/opt

This file has been truncated. show original

With load you might want to update pm.max_children = 8
to a higher value

Create a new template with the xxxx_PHP-8_0.tpl in /usr/local/hestia/data/templates/web/php-fpm

For Grav I assume it is mostly static pages if so consider enabling fastcgi cache this can be done via Edit Webdomain

Ubi · November 24, 2021, 12:11pm

Hi Eris

It’s on page loading.For every pages.I paste here the comparison from chrome inspector network:

Developement server (APACHE mod php 7.3 NO HESTIA)

And with HESTIA with NGINX and PHP-FPM 8.0

Please note the code is exactly the same (cloned versions)

With load you might want to update pm.max_children = 8
to a higher value

I will try, thank you.

Ubi · November 24, 2021, 2:47pm

Tried with a new PHP backend custom template.

pm.max_children = 64

But no improvements. I am thinking it could be related to PECL installation. Everything is in order but I feel something is messing up with PHP APIs between multi php versions on HESTIA. Not sure, the php info shows that everything -regarding PECL YAML and APCU- is fine and enable. This from the phpinfo from GRAV webroot.

Any other ideas?

Thanks

Eduardo · November 25, 2021, 3:33am

Hello,

There is a big difference in those times.

What about the 70 requests?
Usually, the first thing I would do is to study if there are any request(s) that are responsible for those times.

Have you looked at something like the waterfall view?
For example, for www.booking.com it is:

https://www.webpagetest.org/result/211125_BiDcYT_db0df73230f514ad720ef66b9d39fbb2/1/details/#waterfall_view_step1

Where, in those 10 seconds, is most of the delay?

Ubi · November 25, 2021, 6:45am

Hello Eduardo,
thank you for your reply.

Yes a big diffrence. I believe the problem is on compiling PECL modules (YAML and APCu).

When is unistall the modules, YAML for example, i get some errors regarding PHP API (20190902)

While the PHP API Hestia is using for PHP 8.0 is 20200930

When I compile the modules (installing), PECL is asking the PHP API version.

I can set manually the right one or autodetect. No changes and the module is correctly installed

And of course i add the extension in php.ini with single name or the absolute path. No changes.

In PHP info i can see YAML is installed and enabled

One thing i notice is that on APACHE MOD PHP server the yaml.ini is included

While on HESTIA + NGINX + PHP-FPM 8 is not (and maybe is correct because is PHP-FPM, don’t know)

I am sure it’s a conf setting somewhere or i miss something on PHP.FPM but no clue TBH. I tried almost everything i could (including reistalling the whole server multiple times just to be sure)

Where, in those 10 seconds, is most of the delay?

The waterfall is only on index page. This is because the beauty of GRAV is semplicity and the only resource consuming is the YAML pages parsing, made at the very beginning. To help GRAV to do so, the compiled PECL YAML take place.

For example, the APACHE server with NO HESTIA is slow like the HESTIA one if i don’t enable PECL YAML. That’s also why i feel there is something wrong between PECL and HESTIA or PHP-FPM.

Another thing I am not sure is if i have to do something more for PHP.FPM conf, like symlink the librariy or not.

Thanks!

eris · November 25, 2021, 6:52am

Install php-yaml via atp does it work?

https://packages.sury.org/php/pool/main/p/php-yaml/

Ubi · November 25, 2021, 6:56am

nope…

eris · November 25, 2021, 7:00am

php8.0-yaml? according here php-yaml is already installed…

Ubi · November 25, 2021, 7:17am

I was hoping you were right!

But no, no improvements after installing and also rebooting the machine.

caii · November 28, 2021, 3:54am

@Ubi
Disable apcu and you should be fine.
Set apc.enabled = 0 on your /etc/php/8.0/from/php.ini
If you really need opcode cache use php’s by enabling with
opcache.enable=1
opcache.jit=on
You can tweak the memory opcache shared memory storage size.
opcache.memory_consumption = 512
The apcu is very buggy and leads to strange performance issue, tested it and apcu is the cause.

Ubi · November 29, 2021, 9:58am

Hi caii,

Thank you for your tip and insight! Indeed APcu was causing dealys and now the “loading time” drop from 10s to 5s.

Still, on average, 4s slower then a server without HESTIA, but without APCu I got huge speed improvements indeed.

I will keep investigating.

Thank you!