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

Excessive queries to system_setting table causing slow load times #22281

Closed
kimma opened this issue Dec 30, 2022 · 6 comments · Fixed by #22295
Closed

Excessive queries to system_setting table causing slow load times #22281

kimma opened this issue Dec 30, 2022 · 6 comments · Fixed by #22295
Labels
Milestone

Comments

@kimma
Copy link

kimma commented Dec 30, 2022

Description

Dashboard/home screen takes around 3-4 seconds to load.
Have turned on SQL logging, and it seems to be repeating two queries related to Avatars/System Settings for almost the full duration of the request, and then finally serving the page.

Seems related to this new feature listed for 1.18.0
Add system setting table with cache and also add cache supports for user setting (https://github.com/go-gitea/gitea/pull/18058)

It seems no Cache is utilized, since the query is repeated several times for each include of the avatar on the Dashboard/Home page.
Disabling Gravatar support does not affect load times, it simply does not load the Gravatar avatar but still queries the setting multiple times.

The attached log gist is an excerpt from the SQL logs showing all queries ran from hitting "refresh" on the Dashboard page and until NginX returns the result.

Gitea Version

1.18.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/kimma/0ce826ed7f68353c4a22cf422d50cd4c

Screenshots

Footer with load times:
Screenshot 2022-12-30 at 11 47 38

The dashboard in question:
Screenshot 2022-12-30 at 12 32 57

Git Version

No response

Operating System

Kubernetes

How are you running Gitea?

Utilizing the Docker image from docker hub: gitea/gitea:1.18.0
Running in Kubernetes with Galera (mariadb) backend, Redis cache and Minio storage

Database

None

@kimma kimma added the type/bug label Dec 30, 2022
@lunny
Copy link
Member

lunny commented Dec 30, 2022

Have you enabled cache? I think it could resolve the problem.

@kimma
Copy link
Author

kimma commented Dec 30, 2022 via email

@kimma
Copy link
Author

kimma commented Dec 30, 2022

Excerpt from config:

[cache]
ENABLED = true
ADAPTER = redis
HOST    = rediss+sentinel://<redacted>
[cache.last_commit]
ENABLED = true

Is there any Cache config that needs to be set manually?
I see the feature mentions caching but it does indeed not look like it is being utilized for this query.

@lunny
Copy link
Member

lunny commented Dec 31, 2022

Looks like memory cache fix the problem. I will take a look.

@somera
Copy link

somera commented Dec 31, 2022

Is the fix for memcache too?

[cache]
ENABLED = true
ADAPTER = memcache
INTERVAL = 240
HOST = 192.168.178.30:11211
ITEM_TTL = 16h

@lunny
Copy link
Member

lunny commented Dec 31, 2022

Is the fix for memcache too?

[cache]
ENABLED = true
ADAPTER = memcache
INTERVAL = 240
HOST = 192.168.178.30:11211
ITEM_TTL = 16h

Yes. It should be. I have tested with redis but I have no test memcached.

lunny added a commit that referenced this issue Jan 1, 2023
backport #22295, fix #22281

Co-authored-by: Lauris BH <lauris@nix.lv>
lunny added a commit that referenced this issue Jan 1, 2023
Fix #22281

In #21621 , `Get[V]` and `Set[V]` has been introduced, so that cache
value will be `*Setting`. For memory cache it's OK. But for redis cache,
it can only store `string` for the current implementation. This PR
revert some of changes of that and just store or return a `string` for
system setting.
@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants