About server performance

About server performance.

I’ve had my nextcloud instance responding very slowly, so I looked for nextcloud tuning Server tuning — Nextcloud latest Administration Manual latest documentation

Checked performance using both websites :

  1. https://pagespeed.web.dev/ (from Google)

  2. https://yellowlab.tools/ (open source and selfhosted)

  3. https://www.webpagetest.org/ (open source and selfhosted)

The default installation settings did meet the nextcloud guide. So I removed some nextcloud apps that had alternatives in the yunohost catalog. There was a significant improvement. So I looked in the yellowlab tools report. It advised to enable compression (gzip or brotli).

I edited my main nginx config file according to this guide (I know, it’s not the correct way to do it, I’ll move it to a hook) :


gzip on;

gzip_disable "msie6";

gzip_vary on;

gzip_proxied any;

gzip_comp_level 6;

gzip_buffers 16 8k;

gzip_http_version 1.1;

gzip_min_length 1024;

Note that in the original file only the first line was uncommented.

And followed this guide for gzip_types :


gzip_types text/html text/css text/plain text/xml text/x-component text/javascript application/x-javascript application/javascript application/json application/manifest+json application/vnd.api+json application/xml application/xhtml+xml application/rss+xml application/atom+xml application/vnd.ms-fontobject application/x-font-ttf application/x-font-opentype application/x-font-truetype image/svg+xml image/x-icon image/vnd.microsoft.icon font/ttf font/eot font/otf font/opentype;

Then reloaded nginx. There was a noticeable performance improvement for the whole server. Even the yunohost portal loaded much faster. Nextcloud also benefited a little since it has a lot of css.

If you have any recommendations or know any other advices about performance, share them with us.

I remember there were some advice regarding this setting not to activate it, because of a security issue it create.
I don’t know if that’s still valid ?

1 Like

Yes, it’s called “BREACH”, as far as I know it’s very much still a thing and mitigations are not trivial : BREACH - Wikipedia

It’s pretty technical and it’s a weakness only in specific scenarios but that means we can’t really enable by default on YunoHost

However I’m reading:

Another suggested approach is to disable HTTP compression whenever the referrer header indicates a cross-site request, or when the header is not present. This approach allows effective mitigation of the attack without losing functionality, only incurring a performance penalty on affected requests.

which we could investigate to see if it’s easy to implement in nginx

3 Likes

But if I understand correctly, the default nginx configuration does not allow cross site requests and the headers are present as I see here in the following lines :

It’s obvious that improving server performance should never be done at the price of risky security.

I’ve searched for some highly reputed security scan sites and they all reported good results for both my vps (with the altered nginx config) and my home server (with the original nginx config), except for https://securityheaders.com/ that was talking about “referrer-policy”

I’m not an expert at all in nginx, far from that. I’m learning as much as I can, like a lot of yunohost users. So I don’t know what is that, is it important and how to deal with it.

Among other sites I used for scanning : ssllabs.com, sucuri.net. They were all good.

And it’s a an occasion for thanking all of the working team behind yunohost for this amazing gem :gem: and all the users who help each other and contribute as much as they can. :heart_eyes:

1 Like

Following the Wikipedia-link, it seems the BREACH-site has a recommended fix, and a list of alternative fixes.

Most recommended is HTB (“Heal the breach”), a change to the gzip binary. It adds some random bits to the definition of the filename (for what I undestand) in the header of the zipped data. The people that did the research, publicized code with unclear licensing.

Someone with a self-depreciative inclination wrote an alternative version as public domain.

The gzip-fix seems a drop-in replacement, with the caveat that someone has to drop it in from outside regular package management, and trust that it will be kept up to date.t