Server: Remove asset pipeline support

Created on 24 Jun 2016  Â·  18Comments  Â·  Source: nextcloud/server

The asset pipeline support should be removed. See https://help.nextcloud.com/t/asset-pipeline-enabled-leads-to-a-blank-calendar-with-error/1122/5 for details.

0. Needs triage bug

All 18 comments

Some support for this from me, @MorrisJobke and @BernhardPosselt:

  1. HTTP 2 solves the problem
  2. Broken with apps like calendar and contacts (one of them doesn't work properly)
  3. Breaks randomly
  4. Makes your Nextcloud slower (loads different 2 MB on each request)

I'm in favour of making the config switch do nothing for the moment until these problems have all been fixed (e.g. by just concatenating CSS files and have a clever heuristic). It's not like it would really help you anyways… 🙈

JSXC is also broken with this: https://github.com/jsxc/jsxc/issues/255

@schiessle @karlitschek @MorrisJobke @BernhardPosselt Thoughts? My proposal is:

  1. Disable the pipeline for the moment. It has randomly caused broken stuff since ages in oC as well.
  2. Create a ticket to investigate what a simplified less magic pipeline could gain us. (such as by just concat CSS files which would not magically break random stuff)

I vote for disabling it for now. The benefits are questionable!

Concating CSS files will actually hurt you more than help with Http 2 btw

The only benefit I see here is minifaction which I doubt will ever work properly (ES6 is quite a big standard)

removing the asset pipelining support will cause performance losses in galleryplus - won't it?
i enabled it and the preview generation is much faster in the app...

is there no other solution?

@btk999 afaik those are two completely unrelated things.

possible (sorry - im a beginner) - but maybe @oparoz can tell us more? :)

edit:
just found this:

Assets pipelining

Make sure to enable "asset pipelining", so that all the Javascript and CSS resources can be mixed together. This can greatly reduce the loading time of the app.

https://github.com/interfasys/galleryplus

@btk999 right, thats only css and js which is kinda broken and like @LukasReschke mentioned even slowing your instance down

@btk999 @oparoz the gallery app should ship minfied js and css instead. That way you can use whatever tools you want and its significantly faster than the current asset pipeline

@BernhardPosselt Thanks!
Did i get it right? if the feature would work, it would speed up the loading (by mixing js + css).
But the feature is broken and therefore it does not speed up the loading but even slows it down?

im excited for the answer of @oparoz - speeding up the galleryplus would be too great!

@btk999 exactly, in addition it's also broken in that it produces broken output in certain cases :)

speeding up the galleryplus would be too great!

The asset pipeline will definitely not speed up the gallery app. That must something different. It only should speedup the transfer of JS and CSS files to the browser, but as it is implemented in a weird way it actually slows this part down.

I made the recommendation back on the 8.x cycle as it did noticeably shorten the time it takes for the app to load. Back then HTTP/2 wasn't really an option.
I haven't tested the difference lately, but easy minification is a nice thing to have because without it each app needs to include its own PHP minifier and a configuration switch to allow people to turn it off (when debugging)

@btk999 - The easiest way to speed up the gallery apps is to use Redis for files locking. That's a 10x speed improvement when loading albums, especially large ones.

@btk999 - The easiest way to speed up the gallery apps is to use Redis for files locking. That's a 10x speed improvement when loading albums, especially large ones.

Also with 8.2.3+? Because I added a fix for DB based file locking in 8.2.3.

@oparoz thanks! i already use redis and it is really a performance boost!
But with +45gb photos it is just simply slow - so i will try everything for speeding up the app.

i just wanted to be sure, that the feature does not get removed if it is stil be needed. but as far as ai understood, for asset pipelining this is not the case.

Also with 8.2.3+? Because I added a fix for DB based file locking in 8.2.3.

It's slow on stable9, so unless the fix has also been added to the newer branches, then it's still an issue.

But with +45gb photos it is just simply slow

The size of the collection should have little effect. It's more whether it's accessed via the external storage app and if files locking is using Redis.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

arno01 picture arno01  Â·  3Comments

brylie picture brylie  Â·  3Comments

MorrisJobke picture MorrisJobke  Â·  3Comments

williambargent picture williambargent  Â·  3Comments

ChristophWurst picture ChristophWurst  Â·  3Comments