proposal: async update pull_time and pull_count

[chlins]

Fix: goharbor/harbor#15963

Signed-off-by: chlins chenyuzh@vmware.com

[wy65701436]

lgtm

[tianon]

This is slow specifically because it's updating an existing database record, right?

What if instead the code just did an append/insert to some "audit" type table for each event (which should be very fast, given the way the database journaling works) and then have a job that periodically (on a delayed trigger of some kind, maybe?) tallied those up for a combined update that does multiple pulls worth at once?

[chlins]

This is slow specifically because it's updating an existing database record, right?

What if instead the code just did an append/insert to some "audit" type table for each event (which should be very fast, given the way the database journaling works) and then have a job that periodically (on a delayed trigger of some kind, maybe?) tallied those up for a combined update that does multiple pulls worth at once?

@tianon Thanks your advice, but actually we already have the access logs in the audit_log table now which like you say, but the table is too heavy, there are many issues about the audit log is too big or too slow, we also consider some ways to rotate this table, so from this table to retrieve access log and combine them maybe also bring up other performance issues.

[wy65701436]

lgtm