Nextcloud 30 latest Apache Image Slow Loading Times Compared to AIO

[denppa]

When Nextcloud AIO docker is installed side by side with this repo's image, the AIO performs a lot better than this repo's image.

Installed on the same host using the same file system storage backends and ingresses.

Could not install older version so cannot cross verify, but it seems to be introduced by Hub 9 version 30.

[J0WI]

Have configured this image with the same set of DB server, Caching, Redis, nginx, OpenSearch etc.?

[joshtrichards]

Hi @denppa - Thanks for the note. Meant to follow-up on this a few weeks ago too, but @J0WI beat me to it.

---

Follow-up thought that just occurred to me while I typed up the below:

This may simply be due to the PHP 8.3 bump.

AIO is ahead of us on at the moment in that regard. They bumped to PHP 8.3 on November 11th via nextcloud/all-in-one#5575. I have not done benchmarks, but would not be surprised at all if that boosts performance (since that has been PHP's M.O. with most version bumps).

---

My original response was going to be:

It would take a bit of work to create anything resembling an apples-to-apples comparison to AIO. Given we generally use the same underlying base (the php fpm-alpine images) in one of our image variants it could probably be done. But you'd really be comparing the stacks not this image by itself at that point (and only in a very rigid way since there's no way to configure AIO to, for example, not use PostgreSQL, not use Redis, etc.)

Essentially:

• AIO isn't an "image", but a full Nextcloud stack (that is pre-tuned for AIO's envisioned primary use case)
• We're an image, and not a full Nextcloud stack (and not pre-tuned for any particular use case).

We're running (essentially) stock PHP/FPM (and, where applicable, Apache). Those defaults, along with those of any other surrounding parts (Nginx web server, database, memory caching, etc.) are factors for any production deployment and comparison.

We've also got a two image variants (which is a factor since our Alpine images won't perform the same as our default Debian images).

We also have both fpm and apache editions.

I'm not saying you're right or wrong; it's just a little hard to take much from your message without further details. We need more info. :-)

[0ranki]

For what it's worth, I'm also noticing slowness after upgrading to hub 9. I add some packages to the apache image, but I don't think that matters here. Load times aren't that important to me, but after the upgrade from 29 things slowed down enough to start bothering.

If there's anything I can do to help in determining a possible cause, I'm happy to do it. For what it's worth, loading JS and CSS seems to have slowed down a lot, in my instance the login page takes over 8 seconds to load if no assets have been cached by the browser, on the same LAN.

In my case I'm running in k3s, with ingress-nginx in front and Postgres. The ingress is only accessible over IPv6, which is the only major change apart from the version bump recently.
There's a good chance the sluggishness is not related to the image at all, just some configuration issue.

Update: it occurred to me just after writing this to add a hostPort and try accessing the NC pod directly, and load times are near instant. I'd say the image is not the problem, sorry for troubling.