Repository navigation
NextCloud is unacceptably slow without asset pipelining #2272
Description
Activity
I agree that we should try to combine stuff more again, but honestly with a server that takes 6 seconds to deliver a 1kb css file... what are you using it for? downloading a 1MB file will take 6k seconds which is over 1 hour? 😨
And as a sidenote: no one of us has an american-metropol-fiberglas-connection.
Reacted by Liam Dennehy and Stefan BrennerThe problem is really just the latency. Downloading a file works fine with 5–10 MBit/s.
hello,
Use of asset pipeline have already been discussed here : https://help.nextcloud.com/t/asset-pipeline-enabled-leads-to-a-blank-calendar-with-error/1122/4 and in some other thread.
The conclusion was (more or less) : "asset pipeline is old and broken and (very likely) nothing will fix that. Don't use it."
I think that for now, your best options are HTTP/2 and maybe gzip compression of .CSS and .js ...
I think it is important to make a separation between minification and concatination here. In the discussion you are linking, the main argument seems to be that the JavaScript minifier is old and broken. I agree with disabling it then, as an easy solution can be that apps deploy minified JavaScript code, as mentioned in the discussion.
The issue I am facing is not related to a lack minification or compression. It is related to the fact that the browser has to send more than 200 HTTP requests to the server in order to load a page. This problem can only to a small part be solved on an app level. The HTTP standard recommends not to make more than 2 simultaneous connections to a server, and Chrome for example has a hard-coded limit of 6 (see this discussion). HTTP/2 is obviously not a practical solution right now.
If JavaScript files and CSS files (and image sprites) would simply be served concatenated, this would drastically reduce the number of requests and increase performance.
Reacted by Itay Grudev, Mathieu Tarral, Romain DEP., Arthur Darcet, karloluiten, Nicolas K., Christian Reiner, Aykut Çevik, Paulo Moura, nachoparker and 1 more@MorrisJobke Indeed, we could combine all the css easily.
The #2050 pr implement css compression by default.I agree we can improve here. But, havigng said that, the problem should not be that huge. Basically the first page load is painfully slow then. But after that 99% of the assets should be cached anyways.
Reacted by Itay Grudev, zcater, 9662, Aykut Çevik, rubenwardy and Nicolas TurlaisHTTP/2 is obviously not a practical solution right now.
@cdauth Maybe not right now, but... Browser support: http://caniuse.com/#feat=http2 Server adoption: http://isthewebhttp2yet.com/measurements/adoption.html
@cdauth It's actually only supported over TLS (https). Here is a great article about it: https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/ But using nextcloud over an insecure connection is not a good idea anyway.
Okay, I enabled HTTP/2 on my server and the speed improvement is tremendous.
I am undecided whether I think asset pipelining is still necessary.
I think some improvements can still be made (such as avoiding AJAX calls on page load, for example to load the config).
HTTP/2 should definitely be mentioned in the Server Tuning docs.
@cdauth Lucky you, don't have that option, right now.
I think some improvements can still be made (such as avoiding AJAX calls on page load, for example to load the config).
Totally agree 👍
HTTP/2 should definitely be mentioned in the Server Tuning docs.
You could do it yourself 😉
Reacted by John MolakvoæAs HTTP2 is coming, asset pipeline will get obsolete. I don't know if image sprites or CSS compression would still be worth the effort, but I would advise opening dedicated issues and closing this one.
I moved @cdauth's proposal to get rid of some AJAX calls to #2447 and added documentation for HTTP2 in the documentation nextcloud/documentation#242Fresh install on a new server, open Files -> it's 208 requests (!) and 6 sec to load the page ... Just crazy ...
95 remaining items
just update to nextcloud 12 and everything works fine.
Native 12 does not include the
defermechanism, this is scheduled for 13.You can patch your 11 or 12 instance by downloading pull 4854 as a patch:
cd <base directory of nextcloud>
wget https://patch-diff.githubusercontent.com/raw/nextcloud/server/pull/4854.patchThen apply the downloaded patch file to your instance:
patch -p1 < 4854.patchReacted by btk999, Benedikt Geißler, aronovgj, rrrnld and Stefan BrennerThank you very much for this work. I'm still on NC11 and this makes a big difference. FYI 4854 doesn't apply cleanly on NC11 as a few lines in the layout.{base,guest,user}.php are in a different order. Easy to fix by hand though.
I guess the best option, for who can, is to hop and upgrade to NC12 ASAP. If I understand correctly NC12 includes JS combine work. If this is applied on top of it the benefit should be even bigger.
Everyone, thanks for working on this. It is indeed needed to improve loading times.
Maybe many of you are on powerful computers or VPS, but just imagine being on lower end hardware, such as a Raspberry Pi. Think NextCloudPi/Nextcloudbox
From NextCloudPi, we are going steady for 1000~2000 downloads a day, which means at least hundreds of people trying Nextcloud everyday on SBCs. I get many complaints on how slow it is and I can tell that really puts people off. Many decide to stay with Dropbox for this reason.
This screenshot was taken from a NextCloudPi instance on a Raspberry Pi 2 after logging out and logging in again, so browser cache, PHP7, PHP cache, HTTP2 pipelining... and all the stuff
I develop and test on a QEMU ARM virtualized system... just imagine the pain x_x
I am glad to see movement on the right direction. This is just to make you guys aware of this user base that you might not be aware you have.
Good work, and please, don't forget users on low end devices!
edit: I know its a 35$ board, but as someone mentions before, it is quite capable of serving dynamic pages, and I've seen it load faster on PHP5 + owncloud than it does now, so the design can be improved (it is being improved already it seems)
Reacted by Manuel Kuhlmann and marcosmatasHey nachoparker. I didn't know the existence of your project (Nextcloudpi). I installed first owncloud and now nextcloud in my pi2 first and now in my pi3. I suppose that are a lot of people that install nextcloud in this machines for a single use. The server is cheap and the power consuption is very low.
For a perfect personal pi server i think that the project need a mail server. I installed iredmail to make the pi a full server, but i love the simplicity of mail-in-a-box. Please, consider this in future relases.
And yes... when the assets were enabled in previous versions, owncloud was very much faster that now in this machines. I think that this might be solved as soon as possible (is a know error and very evident to forget it).
Nice suggestions! I also want to add email self hosting to the whole thing, but haven't even started investigating.
Would you like to open a feature request / discussion here?
Hi guys,
i applied 4854.patch to my nextcloud 12.0.0, but this makes updating to 12.0.1 impossible.
How can i remove the patch or is there an updated version that works with 12.0.1?Hi guys,
i applied 4854.patch to my nextcloud 12.0.0, but this makes updating to 12.0.1 impossible.
How can i remove the patch or is there an updated version that works with 12.0.1?I removed the patch file in the NC directory and the update went well. I guess you'll have to reapply the patch after update though.
Reacted by btk999Sorry to resume this old thread. This is also not a direct issue of Nextcloud, but it's related. Just want to point out I think HTTP/2 is not really an option at the moment. I've tried with nginx and found it's not ready. HTTP/2 large downloads will simply deadlock. This is not a fault of nextcloud, it's the same with static files if they are big enough (>10 MB can be enough, but it's easier to see with > 100 MB or more).
Apache httpd works, but connection multiplexing doesn't work as I expected. When downloading a large file it's not possible to navigate nextcloud pages. I think (but am not sure at all) this is due to connection multiplexing in HTTP/2, which is done kind of incorrectly in this case. The new requested seems to wait for the big download to finish, but it's supposed to happen concurrently.
@enricotagliavini Downloading a 112 MB file worked pretty fine here (with nginx 1.13 and HTTP/2).
I have been using HTTP2 apache for many months, and it seems very much ready from here :P
@nachoparker so you can download a 10 GB file while surfing to other nextcloud pages at the same time? Which version of apache httpd if I may ask?
Could you please move this discussion to the forum or (if there's a bug) to a new issue? Everyone in this thread will be notified by your comments although it's been fixed. Thanks.
Reacted by Benedikt Geißler- locked and limited conversation to collaborators
on Oct 23, 2017
According to the docs, asset pipelining has been removed in nextCloud 10. While ownCloud/nextCloud has always been very slow, this makes nextCloud extremely slow and practically unusable even on medium-latency connections.
My network connection has ping times of about 250–300 ms to my nextCloud server. This might seem slow compared to a high-speed fiber-glass cable connection in an American metropolis, but it is quite normal for a mobile connection, and in many rural areas in the world the latency is even higher on a cable connection.
I have about 10 non-standard apps installed on my nextCloud instance, and just the front page of the Files app takes anything from 1 minute up to 5 minutes to load (with enabled browser cache)! It tells me that it had to do over 200 requests!
A good web application does 2 or 3 requests to load the page, maybe a bit more for more clever caching, if not all components are needed in all parts of the application.
nextCloud should really:
Here are two screenshots to give a rough idea about what is loading: