NextCloud is unacceptably slow without asset pipelining #2272
Comments
|
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. |
|
The 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. |
|
@MorrisJobke Indeed, we could combine all the css easily. |
|
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. |
@cdauth Maybe not right now, but... Browser support: http://caniuse.com/#feat=http2 Server adoption: http://isthewebhttp2yet.com/measurements/adoption.html |
|
@eppfel: Oh, I must admit that I thought browser support was far less advanced. I was under the impression that HTTP/2 is so far only supported by Chrome when enabling a certain flag. Will look into it and see how much it improves things. |
|
@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.
Totally agree 👍
You could do it yourself 😉 |
|
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. |
|
Fresh install on a new server, open Files -> it's 208 requests (!) and 6 sec to load the page ... Just crazy ... |
|
1Gbps, 0.3 ms latency (LAN Connection) NextCloud 11 Performance analysis of files page:
|
|
the same for me with chrome 55. http2 is enabled together with gzip compression. NextCloud 11 first request: and second cached request: |
|
Loading times are in fact awful atm. I think some form of concatenation is really needed here. HTTP2 won't fix that issue, it is just not as dramatic as with HTTP/1.x. This snippet containing css/js resources was taken from the current nextcloud demo server setup: |
|
In fact, with nextCloud 11, loading times have gone up a lot again, despite HTTP/2. On a low-latency connection where loading times with HTTP/2 were maybe around 4–6 seconds before, they are now around 15 seconds. |
|
I too have noticed drastic increase in overall load times since upgrading to NC 11, not just the initial page. 217 requests, 3,599.67KB, 25s on WiFi LAN, drops to about 15seconds on 1GB wired LAN connection. |
|
ref #1066 |
|
I noticed this really slow load, too. If you are used to NC10 this will prevent you form upgrading to NC11. For me this only happens on Firefox (Version 50.1.0) 8.5 sec loading with cache. With Chrominum ( Version 55.0.2883.87) it loads in 2.9 seconds. |
|
I'm experiencing the same problem. (it has become worse since NC 11). It aren't the PHP requests which are slow (they are fast!) but it's my browser waiting for all the JS and CSS files to load. The screenshot was taken with a fresh profile of Firefox. When the CSS and JS are loaded and you click on a directory in the files app this is very fast. It's just loading all the css and js which is sad because off all the work on the speed up of the PHP side.... I noticed there are some files with 4-5 lines of code and a license header. Also the files aren't minimized or comments are removed. Will it get better because of #1786 ? Especially the compression part. Maybe the same can be done for the JS? |
|
@LEDfan Did you try the scss integration? If so did you find some improvements? |
|
Well I guess the main reason is the number of files, more then what the content of the files is. Although improving both should help twice. |
|
NC 11 indeed is incredibly slow and not usable in production anymore. Furthermore it took me more than an hour to notice that mod_pagespeed is disabled via .htaccess. |
|
This is really not a solution. It is, at best, an attempt to work around the core problem by over-optimizing another layer of the application stack. I don't disagree with the claim that |
Full Ack, That's why I called it "nice-to-have" and "quick-fix" :-) Module bundling? Yes, but f we need "module tidy out"! More than 1 MB (uncomressed) js code - this is enough for an whole operating system. ;) |
|
I agree with @rom1dep. I have my own server, but since I installed stable Debian on it, on which nginx's package doesn't handle http/2, and that there are quite a few services running at the same time, I just can't update my server to testing just like that. Because of that and that I guess I'm not the only one in this situation (as @rom1dep pictured), it would really be nice to have a proper fix on the app side. For sure, HTTP/2 will always be a nice to have, but if Nextcloud doesn't handle this problem seriously, it will only hide it under the rug. |
|
Nextcloud 12 will allow combining JS in apps as per #3988, and also CSS merging. |
|
@LukasReschke Did you (or someone else) made some evaluation (performance measurement) that shows that #3988 is sufficient for everybody and #3696 is really not needed anymore? |
|
Testing the JS Combiner (current master, 4ea79a5) by hard reloading the files app with Firefox 52.
Results: (1) debug=true (no js combine) =>"classic" (2) debug=false (js combine enabled) =>"combined" (3) debug=false (js combine enabled) with additional (4) One XHR request is missing in (3) due to a problem with the files markdown app, see #3696. Chromium needs ~4 sec in either case. |
|
So I would say we need both. 😉 |
|
I'm still very much against this, this changes a core behaviour and has the potential to break apps. This changes the behaviour of loaded JavaScript totally and may make some stuff (e.g. apps that do redirects) even break totally. 👎 – Sorry 😉 |
|
The only reproducible problem I observed so far is the one with files_markdown mentioned above. If we manage to combine all scripts there should be virtually no difference between "combining" and "dark So far - I don't know what is really better... @LukasReschke |
|
Maybe, the new combination approach can still be enhanced. According to the tests by @michaelletzgus, the approach decreased the number of requests from 198 to 117. However, 117 is still very much. Is the approach not yet applied consequently enough or is there something which prevents the number of requests to go down to below, e.g., 20 requests? |
|
@michaelletzgus thanks for your approach! It worked fine on my nextcloud 11.0, but i updated to 11.0.3 and now my instance is slow again. How can i apply your patch on nextcloud 11.0.3? |
|
just update to nextcloud 12 and everything works fine. |
|
Native 12 does not include the You can patch your 11 or 12 instance by downloading pull 4854 as a patch: Then apply the downloaded patch file to your instance: |
|
Thank 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. |
|
For NC11 you can apply #3696. ;)
|
|
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) |
|
Hey 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. |
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. |
|
Sorry 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. |
and others
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:
The text was updated successfully, but these errors were encountered: