Get rid of user activites table and replace it with redis
- Gets rid of the user activities table
- Switch from postgreSQL to Redis
Merge request reports
Activity
@yorickpeterse I'll really appreciate if you can do an initial review of this MR... This one is mainly to get rid of the user activity stuff.
I'm not sure about the redis bit. Is
Gitlab::Redis
using the default cache namespace? Shall I use something else for this?I'll open up a new MR for the API and reading the data bit as this is just so we can keep recording activities.
Reassigned to @yorickpeterse
- Resolved by Yorick Peterse
- Resolved by James Lopez
- Resolved by James Lopez
- Resolved by James Lopez
Reassigned to @jameslopez
- Resolved by James Lopez
Mentioned in issue #1288 (closed)
Added 1 commit:
- 3da15069 - Fixed spec, removed duplicate push count, also updated code based on feedback
Added 1 commit:
- a6226b6a - add extra spec for testing the actual time change in an update
@yorickpeterse updated the code. Can you review again? Also added a spec to double-check we are updating users and not creating new entries.
Edited by James LopezReassigned to @yorickpeterse
- Resolved by James Lopez
@yorickpeterse quick question. Do you know when does the
Gitlab::Redis
cache expire (if ever?) and is there any task or background job that runs that could clean/remove theuser/activities
set ?- Resolved by Yorick Peterse
- Resolved by Yorick Peterse
Reassigned to @jameslopez
Reassigned to @yorickpeterse
@jameslopez I believe it uses the same expiration time as the other data, so 2 weeks. Not entirely sure though, perhaps the automatic TTL is a
Rails.cache
only thing.Edited by Yorick Peterse@yorickpeterse thanks again! left a question https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/915#note_19149221 and a couple of responses to your comments :)
@yorickpeterse ahhh.. We don't want that. That's probably not very useful for the customer as we want to know the users with less activity over time... Is there anything I can do to change that? A new namespace ?
@jameslopez It seems
Gitlab::Redis
does not automatically set a TTL:2.3.2p217 > Gitlab::Redis.with { |r| r.set('foobar', 10) } => "OK" 2.3.2p217 > Gitlab::Redis.with { |r| r.ttl('foobar') } => -1
@yorickpeterse I see, so what will make an entry to expire? I checked the omnibus redis conf but couldn't find anything...
@jameslopez When using
Gitlab::Redis
the entry should not be expired unless one runsFLUSHALL
or Redis somehow loses data.@yorickpeterse perfect! Thanks for your help :) I'll now assign this to an endboss unless you have further questions
@jameslopez Perfect, go ahead.
Reassigned to @rspeicher
@rspeicher can you review this one? Thanks!
- Resolved by James Lopez
- Resolved by James Lopez
- Resolved by James Lopez
Milestone changed to %8.15
@rspeicher any reason to move it to
8.15
? As this was affecting performance I thought it would be more useful to have it in a patch release...@jameslopez The attached issue didn't have a milestone and this wasn't ~"Pick into Stable" so I figured it was a mistake.
ohh right! I'll update... thanks @rspeicher !
Reassigned to @jameslopez
Milestone changed to %8.14
Added 1 commit:
- 423cb005 - fix other spec failures and refactor common stuff into module