Start page: "slow" response time #21031

somera · 2022-09-02T15:47:36Z

Description

This is not a bug. But I try to understand what gitea is doing.

I'm using my gitea for mirror external projects. Means, I have a lot of data. Now I see, that the start page need ~1 second for the first response. Gitea is running in local network.

If I open the gitea start page for user with only one project I see this:

And this result

is for user with a lot of projects.

This is the log for the longer run:

2022/09/02 16:59:14 models/user/user.go:996:GetUserByIDCtx() [I] [63121a42] [SQL] SELECT "id", "lower_name", "name", "full_name", "email", "keep_email_private", "email_notifications_preference", "passwd", "passwd_hash_algo", "must_change_password", "login_type", "login_source", "login_name", "type", "location", "website", "rands", "salt", "language", "description", "created_unix", "updated_unix", "last_login_unix", "last_repo_visibility", "max_repo_creation", "is_active", "is_admin", "is_restricted", "allow_git_hook", "allow_import_local", "allow_create_organization", "prohibit_login", "avatar", "avatar_email", "use_custom_avatar", "num_followers", "num_following", "num_stars", "num_repos", "num_teams", "num_members", "visibility", "repo_admin_change_team_access", "diff_view_style", "theme", "keep_activity_private" FROM "user" WHERE "id"=$1 LIMIT 1 [1] - 1.754489ms
2022/09/02 16:59:14 .../issues/stopwatch.go:132:HasUserStopwatch() [I] [63121a42] [SQL] SELECT "id", "issue_id", "user_id", "created_unix" FROM "stopwatch" WHERE (user_id = $1) LIMIT 1 [1] - 831.954µs
2022/09/02 16:59:14 models/org.go:71:GetUserOrgsList() [I] [63121a42] [SQL] SELECT "user".id,"user".name,"user".full_name,"user".visibility,"user".avatar,"user".avatar_email,"user".use_custom_avatar, count(distinct repo_id) as org_count FROM "user" INNER JOIN "team" ON "team".org_id = "user".id INNER JOIN "team_user" ON "team".id = "team_user".team_id LEFT JOIN (SELECT id as repo_id, owner_id as repo_owner_id FROM repository WHERE ("repository".is_private=$1 AND "repository".owner_id NOT IN (SELECT id FROM "user" WHERE type=$2 AND visibility IN ($3))) OR "repository".id IN (SELECT repo_id FROM "access" WHERE "access".user_id=$4 AND "access".mode>$5) OR "repository".id IN (SELECT "team_repo".repo_id FROM team_repo INNER JOIN team_user ON "team_user".team_id = "team_repo".team_id WHERE "team_user".uid=$6) OR "repository".owner_id=$7 OR ("repository".is_private=$8 AND "repository".owner_id IN (SELECT "org_user".org_id FROM org_user WHERE "org_user".uid=$9))) "repository" ON "repository".repo_owner_id = "team".org_id WHERE ("team_user".uid = $10) GROUP BY "user".id,"user".name,"user".full_name,"user".visibility,"user".avatar,"user".avatar_email,"user".use_custom_avatar ORDER BY "user"."name" ASC [false 1 private 1 0 1 1 false 1 1] - 56.467784ms
2022/09/02 16:59:14 ...ers/web/user/home.go:79:Dashboard() [I] [63121a42] [SQL] SELECT count(*) FROM "org_user" WHERE (uid=$1) [1] - 1.239558ms
2022/09/02 16:59:14 ...dels/user_heatmap.go:71:getUserHeatmapData() [I] [63121a42] [SQL] SELECT created_unix / 900 * 900 AS timestamp, count(user_id) as contributions FROM "action" WHERE user_id=$1 AND act_user_id=$2 AND (created_unix > $3) GROUP BY timestamp ORDER BY timestamp [1 1 1630594754] - 1.663216ms
2022/09/02 16:59:14 ...odels/repo/mirror.go:174:GetUserMirrorRepositories() [I] [63121a42] [SQL] SELECT "id", "owner_id", "owner_name", "lower_name", "name", "description", "website", "original_service_type", "original_url", "default_branch", "num_watches", "num_stars", "num_forks", "num_issues", "num_closed_issues", "num_pulls", "num_closed_pulls", "num_milestones", "num_closed_milestones", "num_projects", "num_closed_projects", "is_private", "is_empty", "is_archived", "is_mirror", "status", "is_fork", "fork_id", "is_template", "template_id", "size", "is_fsck_enabled", "close_issues_via_commit_in_any_branch", "topics", "trust_model", "avatar", "created_unix", "updated_unix" FROM "repository" WHERE (owner_id = $1) AND (is_mirror = $2) [1 true] - 721.573µs
2022/09/02 16:59:14 ...odels/repo/mirror.go:146:loadAttributes() [I] [63121a42] [SQL] SELECT "id", "repo_id", "interval", "enable_prune", "updated_unix", "next_update_unix", "lfs_enabled", "lfs_endpoint" FROM "mirror" WHERE (id > 0) AND "repo_id" IN ($1,$2) [13734 13735] - 463.139µs
2022/09/02 16:59:15 models/action.go:364:GetFeeds() [I] [63121a42] [SQL] SELECT "action".* FROM "action" INNER JOIN "repository" ON "repository".id = "action".repo_id WHERE user_id=$1 AND is_deleted=$2 ORDER BY "action"."created_unix" DESC LIMIT 20 [1 false] - 586.989343ms
2022/09/02 16:59:15 ...odels/action_list.go:39:loadUsers() [I] [63121a42] [SQL] SELECT "id", "lower_name", "name", "full_name", "email", "keep_email_private", "email_notifications_preference", "passwd", "passwd_hash_algo", "must_change_password", "login_type", "login_source", "login_name", "type", "location", "website", "rands", "salt", "language", "description", "created_unix", "updated_unix", "last_login_unix", "last_repo_visibility", "max_repo_creation", "is_active", "is_admin", "is_restricted", "allow_git_hook", "allow_import_local", "allow_create_organization", "prohibit_login", "avatar", "avatar_email", "use_custom_avatar", "num_followers", "num_following", "num_stars", "num_repos", "num_teams", "num_members", "visibility", "repo_admin_change_team_access", "diff_view_style", "theme", "keep_activity_private" FROM "user" WHERE "id" IN ($1,$2,$3,$4) [2039 2040 2042 156] - 718.559µs

This

2022/09/02 16:59:15 models/action.go:364:GetFeeds() [I] [63121a42] [SQL] SELECT "action".* FROM "action" INNER JOIN "repository" ON "repository".id = "action".repo_id WHERE user_id=$1 AND is_deleted=$2 ORDER BY "action"."created_unix" DESC LIMIT 20 [1 false] - 586.989343ms

query is the trigger for the slowdown. And this https://explain.depesz.com/s/BEHk#html is the plan for the query on my instance.

My questions:

Why is gitea exuting this query fot the start page?
More data = longer loading time for the gitea startpage?

Gitea Version

1.17.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.25.1

Operating System

Ubuntu 20.04.4

How are you running Gitea?

Self hosted gitea-1.17.1-linux-amd64

Database

PostgreSQL

The text was updated successfully, but these errors were encountered:

somera · 2022-09-02T16:11:28Z

Answer for the first question: "Why is gitea exuting this query fot the start page?" -> this will be shown on the start page. Last 20 actions.

zeripath · 2022-09-02T16:16:54Z

This is strange because it indicates that the indices are not being used correctly. The plan should look like:

                                               QUERY PLAN                                                
---------------------------------------------------------------------------------------------------------
 Limit  (cost=57.14..57.15 rows=5 width=393)
   ->  Sort  (cost=57.14..57.15 rows=5 width=393)
         Sort Key: action.created_unix DESC
         ->  Nested Loop  (cost=0.57..57.08 rows=5 width=393)
               ->  Index Scan using "IDX_action_user_id" on action  (cost=0.29..15.58 rows=5 width=393)
                     Index Cond: (user_id = 18059)
                     Filter: (NOT is_deleted)
               ->  Index Only Scan using repository_pkey on repository  (cost=0.28..8.30 rows=1 width=8)
                     Index Cond: (id = action.repo_id)
(9 rows)

What is the result of \d action on the psql console?

It should look something like:

                                      Table "public.action"
    Column    |          Type          | Collation | Nullable |              Default               
--------------+------------------------+-----------+----------+------------------------------------
 id           | bigint                 |           | not null | nextval('action_id_seq'::regclass)
 user_id      | bigint                 |           |          | 
 op_type      | integer                |           |          | 
 act_user_id  | bigint                 |           |          | 
 repo_id      | bigint                 |           |          | 
 comment_id   | bigint                 |           |          | 
 is_deleted   | boolean                |           | not null | false
 ref_name     | character varying(255) |           |          | 
 is_private   | boolean                |           | not null | false
 content      | text                   |           |          | 
 created_unix | bigint                 |           |          | 
Indexes:
    "action_pkey" PRIMARY KEY, btree (id)
    "IDX_action_act_user_id" btree (act_user_id)
    "IDX_action_au_r_c_u_d" btree (act_user_id, repo_id, created_unix, user_id, is_deleted)
    "IDX_action_comment_id" btree (comment_id)
    "IDX_action_created_unix" btree (created_unix)
    "IDX_action_is_deleted" btree (is_deleted)
    "IDX_action_is_private" btree (is_private)
    "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted)
    "IDX_action_repo_id" btree (repo_id)
    "IDX_action_user_id" btree (user_id)

somera · 2022-09-02T16:19:24Z

I'm using this

PostgreSQL 13.8 (Ubuntu 13.8-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit

somera · 2022-09-02T16:23:10Z

                                          Tabelle »public.action«
    Spalte    |          Typ           | Sortierfolge | NULL erlaubt? |            Vorgabewert
--------------+------------------------+--------------+---------------+------------------------------------
 id           | bigint                 |              | not null      | nextval('action_id_seq'::regclass)
 user_id      | bigint                 |              |               |
 op_type      | integer                |              |               |
 act_user_id  | bigint                 |              |               |
 repo_id      | bigint                 |              |               |
 comment_id   | bigint                 |              |               |
 is_deleted   | boolean                |              | not null      | false
 ref_name     | character varying(255) |              |               |
 is_private   | boolean                |              | not null      | false
 content      | text                   |              |               |
 created_unix | bigint                 |              |               |
Indexe:
    "action_pkey" PRIMARY KEY, btree (id)
    "IDX_action_au_r_c_u_d" btree (act_user_id, repo_id, created_unix, user_id, is_deleted)
    "IDX_action_comment_id" btree (comment_id)
    "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted)

zeripath · 2022-09-02T16:29:10Z

Ah... I've just seen that there are some "legacy" indices in my example above. I've just got the same schema as you and found the following query plan:

 tc5=# explain select action.* from action inner join "repository" ON "repository".id = "action".repo_id WHERE user_id=18059 AND is_deleted=false ORDER BY "action"."created_unix" DESC LIMIT 20
;
                                               QUERY PLAN                                                
---------------------------------------------------------------------------------------------------------
 Limit  (cost=1677.66..1677.67 rows=5 width=393)
   ->  Sort  (cost=1677.66..1677.67 rows=5 width=393)
         Sort Key: action.created_unix DESC
         ->  Nested Loop  (cost=0.57..1677.60 rows=5 width=393)
               ->  Index Scan using "IDX_action_r_u_d" on action  (cost=0.29..1636.10 rows=5 width=393)
                     Index Cond: ((user_id = 18059) AND (is_deleted = false))
               ->  Index Only Scan using repository_pkey on repository  (cost=0.28..8.30 rows=1 width=8)
                     Index Cond: (id = action.repo_id)
(8 rows)

EDIT: I'd put up the wrong plan this is the right one

zeripath · 2022-09-02T16:31:46Z

Damn I suspect this means that postgres needs different indices to that of MySQL and other DBs and I was led down the garden path by my previous testing with old indices present.

OK I guess we just need to twiddle with the indices until we find the quickest for this.

somera · 2022-09-02T16:33:26Z

Damn I suspect this means that postgres needs different indices to that of MySQL and other DBs and I was led down the garden path by my previous testing with old indices present.

OK I guess we just need to twiddle with the indices until we find the quickest for this.

Ok. Sounds good.

zeripath · 2022-09-02T18:15:16Z

Could you compare which is faster between doing:

CREATE INDEX ON action (user_id, is_deleted)

And:

CREATE INDEX ON action (user_id)

?

somera · 2022-09-02T18:18:57Z

Not faster.

https://explain.depesz.com/s/6vv0

zeripath · 2022-09-02T18:27:56Z

That's very weird because it should be using the index - which your explain does not show. Certainly it works for me.

You will likely need to drop those new indexes before restarting Gitea btw - (I've just discovered that there is a bug in xorm related to its schema reading.)

zeripath · 2022-09-02T18:29:34Z

What version of postgres are you running?

somera · 2022-09-02T18:32:44Z

Added CREATE INDEX ON action (user_id, is_deleted) -> https://explain.depesz.com/s/bqTF

Added CREATE INDEX ON action (user_id) -> https://explain.depesz.com/s/tJisn

Removed CREATE INDEX ON action (user_id, is_deleted) -> https://explain.depesz.com/s/oVKH

somera · 2022-09-02T18:33:07Z

I'm using this

PostgreSQL 13.8 (Ubuntu 13.8-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit

@zeripath here my PG Version.

zeripath · 2022-09-02T18:38:29Z

I just don't understand why it isn't using any of the indices.

I mean this is the plan I get with the user_id and is_deleted index:

;
                                                   QUERY PLAN                                           >
-------------------------------------------------------------------------------------------------------->
 Limit  (cost=61.00..61.02 rows=5 width=393)
   ->  Sort  (cost=61.00..61.02 rows=5 width=393)
         Sort Key: action.created_unix DESC
         ->  Nested Loop  (cost=0.57..60.94 rows=5 width=393)
               ->  Index Scan using action_user_id_is_deleted_idx on action  (cost=0.29..19.44 rows=5 wi>
                     Index Cond: ((user_id = 18059) AND (is_deleted = false))
               ->  Index Only Scan using repository_pkey on repository  (cost=0.28..8.30 rows=1 width=8)
                     Index Cond: (id = action.repo_id)
(8 rows)

It just makes no sense to me that it would not use the index. That's why we have an index. Even the "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted) should have been enough.

zeripath · 2022-09-02T18:39:34Z

I mean you could try:

CREATE INDEX ON action (created_unix DESC)

However, I note that even your no ORDER BY query still isn't using an index.

somera · 2022-09-02T18:45:29Z

I just don't understand why it isn't using any of the indices.

I mean this is the plan I get with the user_id and is_deleted index:

;
                                                   QUERY PLAN                                           >
-------------------------------------------------------------------------------------------------------->
 Limit  (cost=61.00..61.02 rows=5 width=393)
   ->  Sort  (cost=61.00..61.02 rows=5 width=393)
         Sort Key: action.created_unix DESC
         ->  Nested Loop  (cost=0.57..60.94 rows=5 width=393)
               ->  Index Scan using action_user_id_is_deleted_idx on action  (cost=0.29..19.44 rows=5 wi>
                     Index Cond: ((user_id = 18059) AND (is_deleted = false))
               ->  Index Only Scan using repository_pkey on repository  (cost=0.28..8.30 rows=1 width=8)
                     Index Cond: (id = action.repo_id)
(8 rows)

It just makes no sense to me that it would not use the index. That's why we have an index. Even the "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted) should have been enough.

The problem is order by ...

Here the plan without this: https://explain.depesz.com/s/ygq3

somera · 2022-09-02T18:48:00Z

giteadb=# \d action
                                          Tabelle »public.action«
    Spalte    |          Typ           | Sortierfolge | NULL erlaubt? |            Vorgabewert
--------------+------------------------+--------------+---------------+------------------------------------
 id           | bigint                 |              | not null      | nextval('action_id_seq'::regclass)
 user_id      | bigint                 |              |               |
 op_type      | integer                |              |               |
 act_user_id  | bigint                 |              |               |
 repo_id      | bigint                 |              |               |
 comment_id   | bigint                 |              |               |
 is_deleted   | boolean                |              | not null      | false
 ref_name     | character varying(255) |              |               |
 is_private   | boolean                |              | not null      | false
 content      | text                   |              |               |
 created_unix | bigint                 |              |               |
Indexe:
    "action_pkey" PRIMARY KEY, btree (id)
    "IDX_action_au_r_c_u_d" btree (act_user_id, repo_id, created_unix, user_id, is_deleted)
    "IDX_action_comment_id" btree (comment_id)
    "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted)
    "action_created_unix_idx" btree (created_unix DESC)
    "action_user_id_idx" btree (user_id)

Looks better now (~600ms faster for the start page)

https://explain.depesz.com/s/K6u3

somera · 2022-09-02T18:51:38Z

I remved

"action_user_id_idx" btree (user_id)

now.

zeripath · 2022-09-02T18:52:42Z

What the hell is going on:

"Limit  (cost=0.71..19.21 rows=20 width=456) (actual time=0.088..0.371 rows=20 loops=1)"
"  ->  Nested Loop  (cost=0.71..604060.66 rows=653278 width=456) (actual time=0.085..0.358 rows=20 loops=1)"
"        ->  Index Scan using action_created_unix_idx on action  (cost=0.43..404005.15 rows=653278 width=456) (actual time=0.053..0.120 rows=20 loops=1)"
"              Filter: ((NOT is_deleted) AND (user_id = 1))"
"              Rows Removed by Filter: 20"
"        ->  Index Only Scan using repository_pkey on repository  (cost=0.29..0.31 rows=1 width=8) (actual time=0.009..0.009 rows=1 loops=20)"
"              Index Cond: (id = action.repo_id)"
"              Heap Fetches: 20"
"Planning Time: 1.418 ms"
"Execution Time: 0.457 ms"

Why would your db choose to use the index action_created_unix_idx!!

somera · 2022-09-02T18:55:08Z

I don't know. ;)

My action table has 1.307.514 entries.

zeripath · 2022-09-02T18:56:30Z

Maybe you'd benefit from:

CREATE INDEX IDX_action_c_u_d ON action (created_unix DESC, user_id, is_deleted)

Possibly even append an INCLUDE (repo_id) there.

somera · 2022-09-02T18:59:55Z

Maybe you'd benefit from:
CREATE INDEX IDX_action_c_u_d ON action (created_unix DESC, user_id, is_deleted)
Possibly even append an INCLUDE (repo_id) there.

Indexe:
    "action_pkey" PRIMARY KEY, btree (id)
    "IDX_action_au_r_c_u_d" btree (act_user_id, repo_id, created_unix, user_id, is_deleted)
    "IDX_action_comment_id" btree (comment_id)
    "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted)
    "idx_action_c_u_d" btree (created_unix DESC, user_id, is_deleted)

https://explain.depesz.com/s/YJuyr

The start page feels better.

zeripath · 2022-09-02T19:00:53Z

Is that fast enough now?

somera · 2022-09-02T19:01:30Z

Is that fast enough now?

Yes! Thx.

somera · 2022-09-02T19:03:26Z

Should I remove the index

"idx_action_c_u_d" btree (created_unix DESC, user_id, is_deleted)

and wait for the fix release?

zeripath · 2022-09-02T19:12:26Z

OK, now Gitea won't start up with those indexes like that due to a bug in xorm - so we have two problems:

We need to fix xorm to tolerate indexes that don't match the xorm pattern.
I guess we need to add this index by default
- One problem is that xorm can't express DESCing indexes so we should check if the DESC is necessary
- Another is that I'm not sure how applicable this index is to smaller dbs

My large "test" db "only" has 42569 rows in action so I guess this is why I didn't see this.

Could you check if this is still fast:

CREATE INDEX action_c_u_d ON action (created_unix, user_id, is_deleted)

If so that will make fixing this easier.

zeripath · 2022-09-02T19:12:53Z

Yes you will need to remove the index or at least remove it in between restarts.

zeripath · 2022-09-02T19:52:23Z

OK here's the XORM fix: https://gitea.com/xorm/xorm/pulls/2174

Now actually I think we should not drop irregular indices as it is likely that the user has added these deliberately but I guess we should discuss that in another PR.

zeripath · 2022-09-02T20:16:29Z

@somera I've got a few more indexes to check:

CREATE "IDX_action_c_r_u_d" ON action (created_unix, repo_id, user_id, is_deleted)

and

CREATE "IDX_action_c_u_d_r" ON action (created_unix, user_id, is_deleted, repo_id)

If either of those are faster than IDX_action_c_u_d it would be helpful to know.

somera · 2022-09-02T20:18:56Z

OK, now Gitea won't start up with those indexes like that due to a bug in xorm - so we have two problems:

We need to fix xorm to tolerate indexes that don't match the xorm pattern.

I guess we need to add this index by default

One problem is that xorm can't express DESCing indexes so we should check if the DESC is necessary

Another is that I'm not sure how applicable this index is to smaller dbs

My large "test" db "only" has 42569 rows in action so I guess this is why I didn't see this.

Could you check if this is still fast:
CREATE INDEX action_c_u_d ON action (created_unix, user_id, is_deleted)
If so that will make fixing this easier.

Sorry, I didn't see the question.

Here the plan for the index: https://explain.depesz.com/s/JfF9

But the speed is same like with: CREATE INDEX IDX_action_c_u_d ON action (created_unix DESC, user_id, is_deleted)

zeripath · 2022-09-02T20:23:36Z

excellent so the DESC is unnecessary.

What about the repo_id containing ones?

In go-gitea#21031 we have discovered that on very big tables postgres will use a search involving the sort term in preference to the restrictive index. Therefore we add another index for postgres and update the original migration. Fix go-gitea#21031 Signed-off-by: Andrew Thornton <[email protected]>

somera · 2022-09-02T20:30:07Z

excellent so the DESC is unnecessary.

What about the repo_id containing ones?

You mean the user with only one repo?

Works too. Some ms slower.

The plan: https://explain.depesz.com/s/CfHx

Backport go-gitea#21033 In go-gitea#21031 we have discovered that on very big tables postgres will use a search involving the sort term in preference to the restrictive index. Therefore we add another index for postgres and update the original migration. Fix go-gitea#21031 Signed-off-by: Andrew Thornton <[email protected]>

Backport #21033 In #21031 we have discovered that on very big tables postgres will use a search involving the sort term in preference to the restrictive index. Therefore we add another index for postgres and update the original migration. Fix #21031 Signed-off-by: Andrew Thornton <[email protected]>

@tag

commit 32eef4a Author: Lunny Xiao <[email protected]> Date: Wed Sep 7 05:32:20 2022 +0800 Add changelog for v1.17.2 (go-gitea#21089) Co-authored-by: John Olheiser <[email protected]> Co-authored-by: 6543 <[email protected]> Co-authored-by: delvh <[email protected]> Co-authored-by: techknowlogick <[email protected]> commit 449b39e Author: Tyrone Yeh <[email protected]> Date: Tue Sep 6 16:42:05 2022 +0800 Fix sub folder in repository missing add file dropdown (go-gitea#21069) (go-gitea#21083) Backport go-gitea#21069 In repository sub folder missing add file dropdown menu, Probably broken since go-gitea#20602 commit 06f968d Author: zeripath <[email protected]> Date: Tue Sep 6 07:54:47 2022 +0100 Fix hard-coded timeout and error panic in API archive download endpoint (go-gitea#20925) (go-gitea#21051) Backport go-gitea#20925 This commit updates the `GET /api/v1/repos/{owner}/{repo}/archive/{archive}` endpoint which prior to this PR had a couple of issues. 1. The endpoint had a hard-coded 20s timeout for the archiver to complete after which a 500 (Internal Server Error) was returned to client. For a scripted API client there was no clear way of telling that the operation timed out and that it should retry. 2. Whenever the timeout _did occur_, the code used to panic. This was caused by the API endpoint "delegating" to the same call path as the web, which uses a slightly different way of reporting errors (HTML rather than JSON for example). More specifically, `api/v1/repo/file.go#GetArchive` just called through to `web/repo/repo.go#Download`, which expects the `Context` to have a `Render` field set, but which is `nil` for API calls. Hence, a `nil` pointer error. The code addresses (1) by dropping the hard-coded timeout. Instead, any timeout/cancelation on the incoming `Context` is used. The code addresses (2) by updating the API endpoint to use a separate call path for the API-triggered archive download. This avoids producing HTML-errors on errors (it now produces JSON errors). Signed-off-by: Peter Gardfjäll <[email protected]> Signed-off-by: Peter Gardfjäll <[email protected]> Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: Peter Gardfjäll <[email protected]> Co-authored-by: Lunny Xiao <[email protected]> commit 084797b Author: Lunny Xiao <[email protected]> Date: Tue Sep 6 06:48:57 2022 +0800 Fix delete user missed some comments (go-gitea#21067) (go-gitea#21068) commit 7888a55 Author: zeripath <[email protected]> Date: Sun Sep 4 17:17:48 2022 +0100 Delete unreferenced packages when deleting a package version (go-gitea#20977) (go-gitea#21060) Backport go-gitea#20977 Delete a package if its last version got deleted. Otherwise removing the owner works only after the clean up job ran. Fix go-gitea#20969 Co-authored-by: KN4CK3R <[email protected]> commit ea416d7 Author: zeripath <[email protected]> Date: Sun Sep 4 17:17:35 2022 +0100 Redirect if user does not exist on admin pages (go-gitea#20981) (go-gitea#21059) Backport go-gitea#20981 When on /admin/users/ endpoints if the user is no longer in the DB, redirect instead of causing a http 500. Co-authored-by: KN4CK3R <[email protected]> commit 0db6add Author: zeripath <[email protected]> Date: Sun Sep 4 17:17:27 2022 +0100 Set uploadpack.allowFilter etc on gitea serv to enable partial clones with ssh (go-gitea#20902) (go-gitea#21058) Backport go-gitea#20902 When setting.Git.DisablePartialClone is set to false then the web server will add filter support to web http. It does this by using`-c` command arguments but this will not work on gitea serv as the upload-pack and receive-pack commands do not support this. Instead we move these options into the .gitconfig instead. Fix go-gitea#20400 Signed-off-by: Andrew Thornton <[email protected]> Signed-off-by: Andrew Thornton <[email protected]> commit 0ecbb71 Author: qwerty287 <[email protected]> Date: Sun Sep 4 17:12:37 2022 +0200 Fix 500 on time in timeline API (go-gitea#21052) (go-gitea#21057) Backport go-gitea#21052 Before converting a TrackedTime for the API we need to load its attributes - otherwise we get an NPE. Fix go-gitea#21041 commit ea38455 Author: Jason Song <[email protected]> Date: Sun Sep 4 23:12:01 2022 +0800 Fill the specified ref in webhook test payload (go-gitea#20961) (go-gitea#21055) Backport go-gitea#20961 The webhook payload should use the right ref when it‘s specified in the testing request. The compare URL should not be empty, a URL like `compare/A...A` seems useless in most cases but is helpful when testing. commit 8fc80b3 Author: zeripath <[email protected]> Date: Sun Sep 4 16:11:02 2022 +0100 Add another index for Action table on postgres (go-gitea#21033) (go-gitea#21054) Backport go-gitea#21033 In go-gitea#21031 we have discovered that on very big tables postgres will use a search involving the sort term in preference to the restrictive index. Therefore we add another index for postgres and update the original migration. Fix go-gitea#21031 Signed-off-by: Andrew Thornton <[email protected]> commit 71aa64a Author: zeripath <[email protected]> Date: Sun Sep 4 14:59:20 2022 +0100 fix broken insecureskipverify handling in rediss connection uris (go-gitea#20967) (go-gitea#21053) Backport go-gitea#20967 Currently, it's impossible to connect to self-signed TLS encrypted redis instances. The problem lies in inproper error handling, when building redis tls options - only invalid booleans are allowed to be used in `tlsConfig` builder. The problem is, when `strconv.ParseBool(...)` returns error, it always defaults to false - meaning it's impossible to set `tlsOptions.InsecureSkipVerify` to true. Fixes go-gitea#19213 Co-authored-by: Igor Rzegocki <[email protected]> commit 3aba72c Author: zeripath <[email protected]> Date: Sun Sep 4 14:41:21 2022 +0100 Add more checks in migration code (go-gitea#21011) (go-gitea#21050) Backport go-gitea#21011 When migrating add several more important sanity checks: * SHAs must be SHAs * Refs must be valid Refs * URLs must be reasonable Signed-off-by: Andrew Thornton <[email protected]> commit bd1412c Author: José Carlos <[email protected]> Date: Sat Sep 3 21:11:03 2022 +0200 Add Dev, Peer and Optional dependencies to npm PackageMetadataVersion (go-gitea#21017) (go-gitea#21044) Backport go-gitea#21017 Set DevDependencies, PeerDependencies & OptionalDependencies in npm package metadatas Fix go-gitea#21013 commit 3973ce3 Author: silverwind <[email protected]> Date: Sat Sep 3 19:51:09 2022 +0200 Improve arc-green code theme (go-gitea#21039) (go-gitea#21042) Backport go-gitea#21039 - Increase contrasts overall - Add various missing theme classes - Ensure strings and constants are colored the same across languages commit fbde31f Author: Tyrone Yeh <[email protected]> Date: Sat Sep 3 21:36:27 2022 +0800 Add down key check has tribute container (go-gitea#21016) (go-gitea#21038) Backport go-gitea#21016 Fixes an issue where users would not be able to select by pressing the down arrow when using @tag above a message Bug videos: https://user-images.githubusercontent.com/1255041/188095999-c4ccde18-e53b-4251-8a14-d90c4042d768.mp4

somera · 2022-09-07T06:13:58Z

Workx now fine with 1.17.2

somera added the type/bug label Sep 2, 2022

zeripath mentioned this issue Sep 2, 2022

Add another index for Action table on postgres #21033

Merged

zeripath closed this as completed in #21033 Sep 3, 2022

zeripath closed this as completed in 58a80ba Sep 3, 2022

zeripath mentioned this issue Sep 4, 2022

Add another index for Action table on postgres (#21033) #21054

Merged

wxiaoguang mentioned this issue Oct 27, 2022

User dashboard takes a long time to load since 1.17 #21611

Closed

somera mentioned this issue Dec 31, 2022

Start page is 10x slower after update to 1.18.0 #22299

Closed

go-gitea locked and limited conversation to collaborators May 3, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Start page: "slow" response time #21031

Start page: "slow" response time #21031

somera commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

somera commented Sep 2, 2022 •

edited

Loading

zeripath commented Sep 2, 2022 •

edited

Loading

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022 •

edited

Loading

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

zeripath commented Sep 2, 2022 •

edited

Loading

somera commented Sep 2, 2022

somera commented Sep 2, 2022 •

edited

Loading

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022 •

edited

Loading

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

zeripath commented Sep 2, 2022

zeripath commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

somera commented Sep 7, 2022

Start page: "slow" response time #21031

Start page: "slow" response time #21031

Comments

somera commented Sep 2, 2022

Description

Gitea Version

Can you reproduce the bug on the Gitea demo site?

Log Gist

Screenshots

Git Version

Operating System

How are you running Gitea?

Database

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

somera commented Sep 2, 2022 • edited Loading

zeripath commented Sep 2, 2022 • edited Loading

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022 • edited Loading

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

zeripath commented Sep 2, 2022 • edited Loading

somera commented Sep 2, 2022

somera commented Sep 2, 2022 • edited Loading

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022 • edited Loading

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

zeripath commented Sep 2, 2022

zeripath commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

zeripath commented Sep 2, 2022

somera commented Sep 2, 2022

somera commented Sep 7, 2022

somera commented Sep 2, 2022 •

edited

Loading

zeripath commented Sep 2, 2022 •

edited

Loading

zeripath commented Sep 2, 2022 •

edited

Loading

zeripath commented Sep 2, 2022 •

edited

Loading

somera commented Sep 2, 2022 •

edited

Loading

somera commented Sep 2, 2022 •

edited

Loading