Find an issue upstream or file one?

However, that file is a generated when you click Export YAML under Configuration > Info.

IOW, I don't think you can edit it and affect the system.

I diid add opcache.revalidate_freq: "60s" to php.ini found at /app/data/. But this didn't speed things up.

I'm using the copy page button in Admin2 to copy:

It takes 12-16 seconds before I can edit the new copy on the Dockerized version.

In contrast, on the same server, the LAMP version takes ~7 seconds.

The demo server was faster, but yielded similar results (i.e., faster on on the LAMP install).

Thank you!

• Chrome
• Private browsing
• Minimal plugins (e.g., Admin2, API, Login)
• Clearing cache

… but no difference.

Copying a page in Admin2 is still slow.

Thanks for your reply!

It might help to fully describe exactly what you're doing to copy a page and how slow it is, so it can be tested on the demo server as well.

However, copying a page in the GUI is still slow.

CPU usage for both is okay -- but the Disk I/O is quite different: 4.6 GB / 9.6 GB for Docker and 128 MB / 436 MB for LAMP:

Docker:

LAMP:

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

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"

?

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!

• Grav in Docker

• Grav on LAMP

(PM me for password.)

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

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

/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!

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

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

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