Nextcloud time to first byte (TTFB) too long - enable caching

Apparently, there is a redis server running on my stackspin machine - but where is it integrated? Nextcloud and Zulip?

I am having issues with long TTFBs (a few seconds) in Nextcloud, which is driving users mad, and was wondering where I could tweak it to improve performance and especially cache unchanged calendars.

The documentation has no mention of redis and elasticsearch - though both run for Zulip afaik now.
Then the latter could also be used to enable Nextcloud full-text-search, which I will happily contribute when I know the technical underpinnings.

assigned to @varac

moved from stackspin#1289 (moved)

We don't reuse application components on other applications.

We currently have 2 redis instances running:

kubectl get pods -A | grep redis
stackspin-apps   zulip-redis-master-0                           1/1     Running     0          23d
stackspin-apps   nc-redis-master-0                              1/1     Running     0          7d11h

zulip-redis-master-0 is part of Zulip, but that doesn't change anything for your Nextcloud's TTFB.

nc-redis-master-0 is deployed for Onlyoffice, but it's not used by Nextcloud either.

Do you have experience running Nextcloud? Is the TTFB different on Stackspin, compared to non-stackspin/"vanilla" deployments? I'm interested in the data!

How many users are currently using your Nextcloud?

changed title from Document Redis to Nextcloud time to first byte seems long

Do you have experience running Nextcloud?

No, I have wanted to run one for a long time and with Stackspin found the perfect opportunity ;)
But I am reading into the docs and am eager to contribute improvements when I have some time to verify them.

We have about 20 Stackspin Users with ~10 using Nextcloud actively.

The name nc-redis-master-0 is confusing, if it is for OO. So NC should get another redis instance for its caching?

Here are some interesting links I am looking into:

• https://github.com/nextcloud/server/issues/7001
• https://autoize.com/nextcloud-performance-troubleshooting/
• https://haydenjames.io/nginx-tuning-tips-tls-ssl-https-ttfb-latency/

I made a comparison with GCal, and it was about 2 vs 10 seconds because GCal caches a lot.

added User feedback label

changed the description

added 1 deleted label

The name nc-redis-master-0 is confusing, if it is for OO. So NC should get another redis instance for its caching?

True, and actually we do share a MariaDB database between Nextcloud and Onlyoffice, so if it works perfectly we could consider doing the same for Redis.

Looking at the Nextcloud helm chart it seems like it's possible to enable "redis for locking". You could try doing that with a values override, but I'm not sure if it will help improve the TTFB.

https://haydenjames.io/nginx-tuning-tips-tls-ssl-https-ttfb-latency/

I don't think this link is relevant in our use-case, because we use the Apache2 Nextcloud container. And I didn't take a close look, but it seems like this link is about nginx, not nginx-ingress.

I made good experiences with browsertime to test website performance. Until now I only used it for websites which doesn't require a login but there's documentation how to use a selenium pre-script for login.

I'm using our cypress tests for measuring current performance (test runs ~57s on my laptop), and will compare to the changes in caching.

removed 1 deleted label

mentioned in issue stackspin#1290 (closed)

changed title from Nextcloud time to first byte seems long to Nextcloud time to first byte (TTFB) too long - enable caching

Are you sure your NC-OO chart doesn't use the redis for both NC and OO

Because https://docs.nextcloud.com/server/19/admin_manual/configuration_server/caching_configuration.html#memory-caching says:

If you do not install and enable a local memcache you will see a warning on your Nextcloud admin page.

And I don't see such a warning.

But I also don't see the performance I should have with caching.

Apparently, /var/lib/Stackspin/local-storage/pvc-XXXX_stackspin-apps_nextcloud-files/config/apcu.config.php configures apcu as default, but that isn't installed - or is it? I a kinda confused now...

configures apcu as default, but that isn't installed - or is it

Usually, if you use it, it's installed into the PHP Docker image. I haven't fully investigated the nextcloud image, but I wouldn't be surprised if it's running & installed there.

apcu is installed as php extension:

root@nc-nextcloud-9f8996bd-rrk8c:/var/www/html# php -m | grep apcu
apcu

changed milestone to %1.0

changed milestone to %2.1

Sorry that this has been postponed again. We're trying to create smaller milestones for more frequent releases, and there's a lot of stuff for us to work on! We do still plan to work on this issue at some point.

Also, feel free to contribute any improvements meanwhile !

added 1 deleted label