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

Avatar performance improvements #22414

Closed
rullzer opened this issue Feb 16, 2016 · 11 comments
Closed

Avatar performance improvements #22414

rullzer opened this issue Feb 16, 2016 · 11 comments

Comments

@rullzer
Copy link
Contributor

rullzer commented Feb 16, 2016

Curerntly we just store the avatars in /<user>/avatar.jpg (or <user>/avatar.png). While this is simple it also has certain drawbacks. Like the bug we hit with #22119

Further more it would be great to also get avatars of trusted ownClouds locally since we have the vcards anyway.

  1. We should rethink where and how we store avatars (we should still cache generated avatars).
  2. We should actively start caching avatars client side
    • Allow caching of avatars... at least checking validating by etag
    • Your own avatar should be very limited cached since you can update that and want that to be reflected fast
    • Other users avatars can be cached much longer
  3. Our avatar javascript code has become somewhat big and unefficient.
    • We should start using promised (so each avatar is really only checked once per page load).

So basically we should rethink our avatar handling in general.

CC: @PVince81 @DeepDiver1975

@butonic
Copy link
Member

butonic commented Jun 28, 2016

Isn't the avatar something like a thumbnail?

Or should we store it in a dedicated location?

Maybe related #25213

@PVince81
Copy link
Contributor

I'd suggest storing it outside of "/files" so we don't need a full FS setup just to access it.
There are other related issues I met due to syncjob + ldap + avatar + email: #24423 (comment)

Maybe a proper location would be "data/$user/avatar", then if there are multiple sizes they can just be stored there.

@PVince81
Copy link
Contributor

I'm setting this to 9.2 because this have more consequences on performance and other nasty side effects.

@PVince81 PVince81 modified the milestones: 9.2-next, backlog Jun 28, 2016
@DeepDiver1975
Copy link
Member

I'm setting this to 9.2 because this have more consequences on performance and other nasty side effects.

agreed

@PVince81
Copy link
Contributor

Hmmm, just now I thought about modifying initMountsPoints to receive a second argument $homeOnly but realized it won't cover the cases where a cron job runs and wouldn't tear down all the FS. So the best solution is rather to invest time into removing the avatars from the filesystem layer and finding a way to access the avatar list that doesn't require a FS setup.

@PVince81
Copy link
Contributor

PR to move avatars: #25790

@PVince81
Copy link
Contributor

Is the solution from 9.2 that moves the avatars to separate folders already enough to move this ticket to backlog and decrease severity @DeepDiver1975 @butonic ?

@PVince81
Copy link
Contributor

PVince81 commented Dec 6, 2016

Decreasing severity to high

@PVince81
Copy link
Contributor

moving to backlog for now.

Time will tell whether the 10.0 solution of having a separate avatar folder is enough to reduce the severity of this issue. Additional tasks are still valid to further improve avatar handling.

@PVince81 PVince81 modified the milestones: backlog, 10.0 Apr 11, 2017
@SamuAlfageme
Copy link

Also linking #26872 here in case it contributes to decreasing severity and/or close.

@tomneedham tomneedham changed the title The big avatar issue Avatar performance improvements Jul 5, 2018
@stale
Copy link

stale bot commented Sep 21, 2021

This issue has been automatically closed.

@stale stale bot closed this as completed Sep 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants