Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache folder content instead of getting it from the server every time #1611

Closed
jancborchardt opened this issue Oct 3, 2016 · 6 comments · Fixed by #39808
Closed

Cache folder content instead of getting it from the server every time #1611

jancborchardt opened this issue Oct 3, 2016 · 6 comments · Fixed by #39808
Assignees

Comments

@jancborchardt
Copy link
Member

(Original issue opened by @oparoz in the old repo)

Every time we enter a folder, a request is made to apps/files/ajax/list.php in order to get data to build the view.
It can take between 100ms and 500ms to get that information (on top of the time it takes to connect) on a fast server, depending on the folder's content. Probably much more on a Raspberry.

It turns out that even a 100ms delay is noticeable when you do a A/B comparison.

I propose the following change:

  • cache the data structures which are built after receiving fresh data. It might not be possible to cache everything because of the memory it would require I guess.
  • send the folder's etag to list.php
  • the server returns an empty files array if the etag is the same as the current one
  • the client uses either the cache or the fresh data, depending on if there's been an etag change or not

Letting the Files experts decide if that's feasible and worth it
@schiessle @LukasReschke @icewind1991

@LukasReschke
Copy link
Member

I'd do it the other way around, just send a subfolder listing back as well in the top parent node. So if I'm in the folder /bar/ I also get the response back for /bar/foo and /bar/bar and an ETAG.

Once we then enter the subfolder it's subfolders and ETAGs are requested as well.

I'm not entirely sure how this would behave with external storages, @icewind1991. Thoughts on that?

@nickvergessen
Copy link
Member

The problem is, that a change in the share information, and favoriting/commenting does not change the etag... Therefor you would then need to do a hard refresh to see if something changed....

@oparoz
Copy link
Member

oparoz commented Oct 5, 2016

Well, we could still refresh the page like we do now, but just not get the list of files if we know things haven't changed. I'm not sure how it works in the back-end. I'm assuming you can do partial retrieval of data if a comment has been added per example.

@rullzer
Copy link
Member

rullzer commented Oct 6, 2016

We use webdav now. So we can just do etag magic. Which might be a ton of fun in javascript ...

But as @nickvergessen points out not all info will be updated then. And we currently (besides polling) have no way to get notified about new comments or shares. Of course we could still fire off a request in the background. And rerender stuff as needed. But that to will be a major rewrite.

@nextcloud-bot nextcloud-bot added the stale Ticket or PR with no recent activity label Jun 20, 2018
@skjnldsv skjnldsv added the 1. to develop Accepted and waiting to be taken care of label Jun 12, 2019
@ghost ghost removed the stale Ticket or PR with no recent activity label Jun 12, 2019
@szaimen
Copy link
Contributor

szaimen commented May 21, 2021

I suppose this issue is still valid? If not, please close this issue!

@skjnldsv skjnldsv added 2. developing Work in progress and removed 1. to develop Accepted and waiting to be taken care of labels Jun 22, 2023
@skjnldsv
Copy link
Member

Built-in files to vue.
Will close as soon as all views are migrated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

8 participants