Grav 2.0 - copying a page is slow

[superhua]

(This is a stretch, but I'm not sure where else to post.)

Copying a page in Grav 2.0/Admin 2.0 is slow (~12 seconds).

The Grav support forum suggests it is not a Grav issue, but may be a server/network issue.

From the log below (which shows long POST and PATCH requests of 3 and 6 seconds respectively), is there anything that would suggest this is related to how Cloudron configures things?

Jul 09 08:01:10 149.154.20.112 - - [09/Jul/2026:12:01:10 +0000] "GET /api/v1/pages?children_of=%2F&sort=order&order=asc&per_page=200&page=1 HTTP/1.1" 200 2599 "https://examplesite.org/admin/pages/edit/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5 Safari/605.1.15"
Jul 09 08:01:11 149.154.20.112 - - [09/Jul/2026:12:01:10 +0000] "POST /api/v1/pages/test/copy HTTP/1.1" 201 6063 "https://examplesite.org/admin/pages/edit/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5 Safari/605.1.15"
Jul 09 08:01:14 - - - [09/Jul/2026:12:01:14 +0000] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.4.58 (Ubuntu) mod_perl/2.0.13 Perl/v5.38.2 (internal dummy connection)"
Jul 09 08:01:17 149.154.20.112 - - [09/Jul/2026:12:01:11 +0000] "PATCH /api/v1/pages/test-2 HTTP/1.1" 200 6069 "https://examplesite.org/admin/pages/edit/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5 Safari/605.1.15"
Jul 09 08:01:23 - - - [09/Jul/2026:12:01:20 +0000] "GET / HTTP/1.1" 302 - "-" "Mozilla (CloudronHealth)"
Jul 09 08:01:23 149.154.20.112 - - [09/Jul/2026:12:01:17 +0000] "GET /api/v1/reports/twig-content/page?route=%2Ftest-2 HTTP/1.1" 200 80 "https://examplesite.org/admin/pages/edit/test-2" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5 Safari/605.1.15"

[james]

Hello @superhua
Without more details about your set-up it is close to impossible to make an assumption what the issue could be.
It might be the systems IO, network speed or something else.
Maybe you can check your browser console with these request if they really take this long.
If the browser console reports back faster the web log viewer it might be system related.

Maybe also provide the output of cloudron-support --troubleshoot so we can get a better understand of what you are working with.

[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.)