Grav 2.0 - copying a page is slow

[superhua]

@james Thank you. I totally understand that this is nearly impossible to diagnose. Feels like such an odd issue.

Anyhow, not sure which aspect of the browser console would be helpful, but the long wait times are confirmed:

Further, here is the output of cloudron-support --troubleshoot:

Vendor: Red Hat Product: KVM
Linux: 5.15.0-185-generic
Ubuntu: jammy 22.04
Cloudron: 9.2.0
Execution environment: kvm
Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz x 4
RAM: 8127812KB
Disk: /dev/vda4        16G
[OK]	Root disk usage is OK (82%)
[OK]	Memory usage is OK (53%)
[OK]	Clock is NTP-synchronized
[OK]	node version is correct
[OK]	IPv6 is enabled in kernel. No public IPv6 address
[OK]	docker is running
[OK]	docker version is correct
[OK]	MySQL is running
[OK]	netplan is good
[OK]	DNS is resolving via systemd-resolved
[OK]	unbound is running
[OK]	IPv4 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[SKIP]	IPv6 HTTPS to api.cloudron.io/api/v1/helper/public_ip — no public IPv6 address
[OK]	IPv4 HTTPS to auth.docker.io/token
[SKIP]	IPv6 HTTPS to auth.docker.io/token — no public IPv6 address
[OK]	IPv4 HTTPS to acme-v02.api.letsencrypt.org
[SKIP]	IPv6 HTTPS to acme-v02.api.letsencrypt.org — no public IPv6 address
[OK]	nginx is running
[OK]	dashboard cert is valid
[OK]	dashboard is reachable via loopback
[OK]	No pending database migrations
[OK]	Service 'mysql' is running and healthy
[OK]	Service 'postgresql' is running and healthy
[OK]	Service 'mongodb' is running and healthy
[OK]	Service 'mail' is running and healthy
[OK]	Service 'graphite' is running and healthy
[OK]	Service 'sftp' is running and healthy
[OK]	box v9.2.0 is running
[OK]	Dashboard is reachable via IPv4 (https://my.indychinesechurch.org)
[SKIP]	Dashboard IPv6 reachability — no public IPv6 address
[SKIP]	Domain expiry check — whois not installed; run 'apt install whois' to check

======== Summary ========
PASS:  26
WARN:  0
FAIL:  0
SKIP:  5

[james]

Hello @superhua
/dev/vda4 hints that this is a virtual disk.
You should check the disk speeds it could be it is very slow for some reason.
Also, IOWAIT might be worth looking at.

Not that your hoster is having file storage issues and your system is just slow because of that.

[superhua]

hdparm -Tt /dev/vda4 yields:

/dev/vda4:
 Timing cached reads:   9658 MB in  1.99 seconds = 4846.98 MB/sec
 Timing buffered disk reads: 896 MB in  3.00 seconds = 298.61 MB/sec

Wait time (wa) using vmstat 1 is 0 or 1.

These numbers look good.

I'll continue to research and report back if I discover anything.

Thanks again for your help!

[superhua]

Update: Installing Grav on the Cloudron LAMP App yields faster copy times (about twice as fast).

Thus, perhaps it is something related to the Dockerization of it?

[robi]

Does grav on the demo server have the same pattern?

[superhua]

@robi – Good idea!
Yes, after installing Grav and LAMP (and then Grav on top of that), LAMP/Grav is still faster on the demo server.

[robi]

@superhua perfect for @james to take a peek.

Drop the app subdomains of the demo server to help him out.

[superhua]

@james Here are the two test sites:

• Grav in Docker

• Grav on LAMP

(PM me for password.)

[nebulon]

If both those apps are installed and using the same disk, I can't quite see how filesystem operations would in any case impact how Grav is serving up files. On top of this, the Grav package is also using apache to serve up the files.

[superhua]

@nebulon Thanks for the reply.

Yes, both apps are installed and using the same disk.

Good to know the Grav package is also using Apache.

Quite a mystery why there is a difference in speed then!

[superhua]

Would the following making any difference?

grav-system-info.yaml from the Dockerized install has opcache.revalidate_freq: "2s"

while

grav-system-info.yaml from LAMP install has opcache.revalidate_freq: "60s"

?

[james]

Hello @superhua
The official docker image of grav is also settings this to 2s.
See: https://github.com/getgrav/docker-grav/blob/89920ea92715261adee817dc7d74f366621af5c9/config/php-grav.ini#L32

[robi]

@superhua change it and test?

How's the CPU usage for both during the op?