Horrible Dashboard Delay After Upgrade #13579

@bsofiato commented on GitHub (Oct 10, 2024):

Hey @lunny, I have a somewhat large instance of Gitea running on my machine (at least I think it is large -- its actions table has almost 13 million rows).

I've created an index based on the action's user_id and is_deleted columns and the cost of the queries has dropped from 61923.66 to about 8). The database is Postgres.

I don't know if such an index would have other implications that I'm unaware of. But if you think that adding the index would be a sensible approach, I would gladly submit a PR for it.

@bsofiato commented on GitHub (Oct 10, 2024): Hey @lunny, I have a somewhat large instance of Gitea running on my machine (at least I think it is large -- its actions table has almost 13 million rows). I've created an index based on the action's user_id and is_deleted columns and the cost of the queries has dropped from 61923.66 to about 8). The database is Postgres. I don't know if such an index would have other implications that I'm unaware of. But if you think that adding the index would be a sensible approach, I would gladly submit a PR for it.

GiteaMirror commented

@lunny commented on GitHub (Oct 10, 2024):

According to the current index function, I think maybe you are right, we need that index. Please send a PR to fix this.

// TableIndices implements xorm's TableIndices interface
func (a *Action) TableIndices() []*schemas.Index {
	repoIndex := schemas.NewIndex("r_u_d", schemas.IndexType)
	repoIndex.AddColumn("repo_id", "user_id", "is_deleted")

	actUserIndex := schemas.NewIndex("au_r_c_u_d", schemas.IndexType)
	actUserIndex.AddColumn("act_user_id", "repo_id", "created_unix", "user_id", "is_deleted")

	cudIndex := schemas.NewIndex("c_u_d", schemas.IndexType)
	cudIndex.AddColumn("created_unix", "user_id", "is_deleted")

	indices := []*schemas.Index{actUserIndex, repoIndex, cudIndex}

	return indices
}

@lunny commented on GitHub (Oct 10, 2024): According to the current index function, I think maybe you are right, we need that index. Please send a PR to fix this. ```go // TableIndices implements xorm's TableIndices interface func (a *Action) TableIndices() []*schemas.Index { repoIndex := schemas.NewIndex("r_u_d", schemas.IndexType) repoIndex.AddColumn("repo_id", "user_id", "is_deleted") actUserIndex := schemas.NewIndex("au_r_c_u_d", schemas.IndexType) actUserIndex.AddColumn("act_user_id", "repo_id", "created_unix", "user_id", "is_deleted") cudIndex := schemas.NewIndex("c_u_d", schemas.IndexType) cudIndex.AddColumn("created_unix", "user_id", "is_deleted") indices := []*schemas.Index{actUserIndex, repoIndex, cudIndex} return indices } ```

GiteaMirror commented

@lunny commented on GitHub (Oct 10, 2024):

I think the 61923.66 to about 8 means ms?

@lunny commented on GitHub (Oct 10, 2024): I think the `61923.66 to about 8` means ms?

GiteaMirror commented

@lunny commented on GitHub (Oct 10, 2024):

Looks like we already have the index definition. cudIndex.AddColumn("created_unix", "user_id", "is_deleted") which will be used in find function, but for counting , the Desc("action.created_unix") will be ignored. @bsofiato Can you post your two SQL's execution time. One is for counting, and the other one is for finding.

@lunny commented on GitHub (Oct 10, 2024): Looks like we already have the index definition. `cudIndex.AddColumn("created_unix", "user_id", "is_deleted")` which will be used in find function, but for counting , the `Desc("`action`.created_unix")` will be ignored. @bsofiato Can you post your two SQL's execution time. One is for counting, and the other one is for finding.

GiteaMirror commented

@bsofiato commented on GitHub (Oct 11, 2024):

I think the 61923.66 to about 8 means ms?

Nope, it is more like an arbitrary unit of costs. This article does a great job of explaining the concept.

Looks like we already have the index definition. cudIndex.AddColumn("created_unix", "user_id", "is_deleted") which will be used in find function, but for counting , the Desc("action.created_unix") will be ignored. @bsofiato Can you post your two SQL's execution time. One is for counting, and the other one is for finding.

For sure. The first screen shot shows the cost when using the indexes that are already in place. See that it uses the IDX_action_user_id index and it performs a scan filtering it by the is_deleted column.

For fetching whe get the results below.

If I apply the command CREATE INDEX action_user_id_idx ON public."action" (user_id,is_deleted); and rerun the query I get the results below.

The results below show the fetching results.

As of what is happening with the cudIndex.AddColumn("created_unix", "user_id", "is_deleted") index. AFAIK, a composite index can only be used if the criterion spans its leftmost columns. To check if this hypothesis is correct, I've created another index on on which the created_unix is placed last. The query cost were similar to the 2nd scenario.

Fetching results:

If the created_unix is not used in any criteria (i.e., only used to order results), I think we could safely reorder the index columns to make it more selective. Otherwise, I think the solution would be to create another index.

@bsofiato commented on GitHub (Oct 11, 2024): > I think the `61923.66 to about 8` means ms? Nope, it is more like an arbitrary unit of costs. This [article](https://scalegrid.io/blog/postgres-explain-cost/) does a great job of explaining the concept. > Looks like we already have the index definition. `cudIndex.AddColumn("created_unix", "user_id", "is_deleted")` which will be used in find function, but for counting , the `Desc("`action`.created_unix")` will be ignored. @bsofiato Can you post your two SQL's execution time. One is for counting, and the other one is for finding. For sure. The first screen shot shows the cost when using the indexes that are already in place. See that it uses the `IDX_action_user_id` index and it performs a scan filtering it by the is_deleted column. ![image](https://github.com/user-attachments/assets/b1d9c958-8ce3-4fc1-8d4a-89daaa7d3b90) For fetching whe get the results below. ![image](https://github.com/user-attachments/assets/bb1463f7-3ddd-40a4-944c-8bf32a06aae9) If I apply the command `CREATE INDEX action_user_id_idx ON public."action" (user_id,is_deleted);` and rerun the query I get the results below. ![image](https://github.com/user-attachments/assets/03bd4db3-735d-42ce-bb64-8b217e8a2627) The results below show the fetching results. ![image](https://github.com/user-attachments/assets/c13d8a4d-ffe3-4d96-9129-75fbda29cecb) As of what is happening with the `cudIndex.AddColumn("created_unix", "user_id", "is_deleted")` index. AFAIK, a composite index can only be used if the criterion spans its leftmost columns. To check if this hypothesis is correct, I've created another index on on which the `created_unix` is placed last. The query cost were similar to the 2nd scenario. ![image](https://github.com/user-attachments/assets/c695ede5-89dd-4e0d-a136-bd1fb1d567ae) Fetching results: ![image](https://github.com/user-attachments/assets/dd7af820-7969-4481-8c3f-b5a008002b61) If the `created_unix` is not used in any criteria (i.e., only used to order results), I think we could safely reorder the index columns to make it more selective. Otherwise, I think the solution would be to create another index.

GiteaMirror commented

@lunny commented on GitHub (Oct 11, 2024):

Can you try select * from action where user_id=? and is_deleted=? order by created_unix desc? This should be the SQL Gitea used in the dashboard.

@lunny commented on GitHub (Oct 11, 2024): Can you try `select * from action where user_id=? and is_deleted=? order by created_unix desc`? This should be the SQL Gitea used in the dashboard.

GiteaMirror commented

@somera commented on GitHub (Oct 11, 2024):

In my case I see improvements which was made in #31752. In my action table are 3977694 entries. And this
Dauer: 1471.509 ms Ausführen <unnamed>: SELECT count(*) FROM "action" WHERE user_id=$1 AND is_deleted=$2
query needs ~1,5 seconds, if the data is cached. First call after reboot need ~8 seconds. But this is ok. My Gitea and PostgreSQL 16 run on an 4 core NUC with 32 GB RAM.

Idea: The count query could by cached and invalidated when there are changes in the action table? this would speedup this. Depends how often something changes in the action table.

I missing only some improvements on the higher pages on pagging. Cause there sorting is consuming too much RAM.

I mean this query

SELECT
	"id", "user_id", "op_type", "act_user_id", "repo_id", "comment_id", "is_deleted", "ref_name", "is_private", "content", "created_unix"
FROM
	"action"
WHERE
	user_id=1 AND is_deleted='f'
ORDER BY "action"."created_unix" DESC LIMIT 20 OFFSET 1976620

And the optimizes query need less RAM

@somera commented on GitHub (Oct 11, 2024): In my case I see improvements which was made in #31752. In my action table are 3977694 entries. And this ```Dauer: 1471.509 ms Ausführen <unnamed>: SELECT count(*) FROM "action" WHERE user_id=$1 AND is_deleted=$2``` query needs ~1,5 seconds, if the data is cached. First call after reboot need ~8 seconds. But this is ok. My Gitea and PostgreSQL 16 run on an 4 core NUC with 32 GB RAM. **Idea: The count query could by cached and invalidated when there are changes in the action table? this would speedup this. Depends how often something changes in the action table.** I missing only some improvements on the higher pages on pagging. Cause there sorting is consuming too much RAM. I mean this query ``` SELECT "id", "user_id", "op_type", "act_user_id", "repo_id", "comment_id", "is_deleted", "ref_name", "is_private", "content", "created_unix" FROM "action" WHERE user_id=1 AND is_deleted='f' ORDER BY "action"."created_unix" DESC LIMIT 20 OFFSET 1976620 ``` ![image](https://github.com/user-attachments/assets/baeca099-9ca1-4bf2-bb49-453d1c17eb59) And the optimizes query need less RAM ![image](https://github.com/user-attachments/assets/d463296c-c2a0-48a9-8c25-1dfad39ad620)

GiteaMirror commented

@somera commented on GitHub (Oct 11, 2024):

I've created an index based on the action's user_id and is_deleted columns and the cost of the queries has dropped from 61923.66 to about 8). The database is Postgres.

How is your Postgres RAM configuration? In my case I saw a lot of tmp-files and I increased some parameters.

shared_buffers = 8GB
temp_buffers = 2GB
work_mem = 6GB
max_wal_size = 2GB
min_wal_size = 512MB
effective_cache_size = 4GB

This was an improvement.

And this https://explain.depesz.com/ make the explain result more readable.

@somera commented on GitHub (Oct 11, 2024): > I've created an index based on the action's user_id and is_deleted columns and the cost of the queries has dropped from 61923.66 to about 8). The database is Postgres. How is your Postgres RAM configuration? In my case I saw a lot of tmp-files and I increased some parameters. ``` shared_buffers = 8GB temp_buffers = 2GB work_mem = 6GB max_wal_size = 2GB min_wal_size = 512MB effective_cache_size = 4GB ``` This was an improvement. And this https://explain.depesz.com/ make the explain result more readable.

GiteaMirror commented

@bsofiato commented on GitHub (Oct 11, 2024):

Can you try select * from action where user_id=? and is_deleted=? order by created_unix desc? This should be the SQL Gitea used in the dashboard.

For sure. I just added limit to the end of the query (since the dashboard is paged, I assume it is)

The original index yields the results below:

In the other hand, we get the following results when using the (user_id, is_deleted) index. Notice that postgre still uses the same index.

After that, I've added created the (user_id, is_deleted, created_unix) index. Which resulted in:

Lastly, I've tried to create the index as (is_deleted, user_id, created_unix) index. The results was:

Tha last two index are pratically equal in terms of performance (the actual cost of the 4th being marginally lower).

I've created an index based on the action's user_id and is_deleted columns and the cost of the queries has dropped from 61923.66 to about 8). The database is Postgres.

How is your Postgres RAM configuration? In my case I saw a lot of tmp-files and I increased some parameters.
shared_buffers = 8GB
temp_buffers = 2GB
work_mem = 6GB
max_wal_size = 2GB
min_wal_size = 512MB
effective_cache_size = 4GB
This was an improvement.

And this https://explain.depesz.com/ make the explain result more readable.

I'll have to check it out. But I'm pretty sure no tuning was made to this particular database since it used mainly for development.

BTW, nice tool :)

@bsofiato commented on GitHub (Oct 11, 2024): > Can you try `select * from action where user_id=? and is_deleted=? order by created_unix desc`? This should be the SQL Gitea used in the dashboard. For sure. I just added limit to the end of the query (since the dashboard is paged, I assume it is) The original index yields the results below: ![image](https://github.com/user-attachments/assets/2f1c0250-bf4d-41c9-895c-f41d349931f6) In the other hand, we get the following results when using the (user_id, is_deleted) index. Notice that postgre still uses the same index. ![image](https://github.com/user-attachments/assets/6403219d-05b1-4379-a824-94f23bf574fe) After that, I've added created the (user_id, is_deleted, created_unix) index. Which resulted in: ![image](https://github.com/user-attachments/assets/d15d0c57-b037-49f5-87b3-d33e3f4f2ffe) Lastly, I've tried to create the index as (is_deleted, user_id, created_unix) index. The results was: ![image](https://github.com/user-attachments/assets/1bc08068-fe50-43b7-ac7c-548ba05db222) Tha last two index are pratically equal in terms of performance (the actual cost of the 4th being marginally lower). > > I've created an index based on the action's user_id and is_deleted columns and the cost of the queries has dropped from 61923.66 to about 8). The database is Postgres. > > How is your Postgres RAM configuration? In my case I saw a lot of tmp-files and I increased some parameters. > > ``` > shared_buffers = 8GB > temp_buffers = 2GB > work_mem = 6GB > max_wal_size = 2GB > min_wal_size = 512MB > effective_cache_size = 4GB > ``` > > This was an improvement. > > And this https://explain.depesz.com/ make the explain result more readable. I'll have to check it out. But I'm pretty sure no tuning was made to this particular database since it used mainly for development. BTW, nice tool :)

GiteaMirror commented

@lunny commented on GitHub (Oct 11, 2024):

The index sequence maybe affect the final performance result. I guess index (user_id, is_deleted, created_unix) maybe different from (created_unix, user_id, is_deleted) which is the index in the current version of Gitea.

@lunny commented on GitHub (Oct 11, 2024): The index sequence maybe affect the final performance result. I guess index `(user_id, is_deleted, created_unix)` maybe different from `(created_unix, user_id, is_deleted)` which is the index in the current version of Gitea.

GiteaMirror commented

@bsofiato commented on GitHub (Oct 11, 2024):

The index sequence maybe affect the final performance result. I guess index (user_id, is_deleted, created_unix) maybe different from (created_unix, user_id, is_deleted) which is the index in the current version of Gitea.

Yeap. I think the main culprit is indeed the order of the columns in the index. If you guys are okay with it. I think I can supply a PR for that during the weekend.

@bsofiato commented on GitHub (Oct 11, 2024): > The index sequence maybe affect the final performance result. I guess index `(user_id, is_deleted, created_unix)` maybe different from `(created_unix, user_id, is_deleted)` which is the index in the current version of Gitea. Yeap. I think the main culprit is indeed the order of the columns in the index. If you guys are okay with it. I think I can supply a PR for that during the weekend.

GiteaMirror commented

@somera commented on GitHub (Oct 11, 2024):

I added this

CREATE INDEX IF NOT EXISTS "IDX_action_u_d_c"
    ON public.action USING btree
    (user_id ASC NULLS LAST, is_deleted ASC NULLS LAST, created_unix ASC NULLS LAST)
    TABLESPACE pg_default;

CREATE INDEX IF NOT EXISTS "IDX_action_u_d"
    ON public.action USING btree
    (user_id ASC NULLS LAST, is_deleted ASC NULLS LAST)
    TABLESPACE pg_default;

But I can't see, that this will be used.

SELECT count(*) FROM "action" WHERE user_id=1 AND is_deleted='f' :

and

SELECT
"id"
FROM
"action"
WHERE
user_id=1 AND is_deleted='f'
ORDER BY "action"."created_unix" DESC LIMIT 20 OFFSET 1976620:

@somera commented on GitHub (Oct 11, 2024): I added this ``` CREATE INDEX IF NOT EXISTS "IDX_action_u_d_c" ON public.action USING btree (user_id ASC NULLS LAST, is_deleted ASC NULLS LAST, created_unix ASC NULLS LAST) TABLESPACE pg_default; CREATE INDEX IF NOT EXISTS "IDX_action_u_d" ON public.action USING btree (user_id ASC NULLS LAST, is_deleted ASC NULLS LAST) TABLESPACE pg_default; ``` But I can't see, that this will be used. SELECT count(*) FROM "action" WHERE user_id=1 AND is_deleted='f' : ![image](https://github.com/user-attachments/assets/cc29626b-aa18-499b-b91b-efa01ed1c34a) and SELECT "id" FROM "action" WHERE user_id=1 AND is_deleted='f' ORDER BY "action"."created_unix" DESC LIMIT 20 OFFSET 1976620: ![image](https://github.com/user-attachments/assets/fa6092de-227f-406b-af58-d74db8746111)

GiteaMirror commented

@SoulSeekkor commented on GitHub (Oct 11, 2024):

@lunny

I will investigate it. How many records in the table action.

There are 847525 records in the action table.

@SoulSeekkor commented on GitHub (Oct 11, 2024): > > @lunny > > I will investigate it. How many records in the table action. There are 847525 records in the action table.

GiteaMirror commented

@bsofiato commented on GitHub (Oct 22, 2024):

@lunny is this still a thing ? It flew completely under my radar :(

@bsofiato commented on GitHub (Oct 22, 2024): @lunny is this still a thing ? It flew completely under my radar :(

GiteaMirror commented

@lunny commented on GitHub (Oct 22, 2024):

@lunny is this still a thing ? It flew completely under my radar :(

Yes, I think maybe we need a new index for user_id and is_deleted without updated_unix.

@lunny commented on GitHub (Oct 22, 2024): > @lunny is this still a thing ? It flew completely under my radar :( Yes, I think maybe we need a new index for `user_id` and `is_deleted` without `updated_unix`.

GiteaMirror commented

@lunny commented on GitHub (Oct 24, 2024):

@lunny is this still a thing ? It flew completely under my radar :(

I created #32333 to resolve the problem.
@somera and @SoulSeekkor Do you have any condition to do a test for the problem?

@lunny commented on GitHub (Oct 24, 2024): > @lunny is this still a thing ? It flew completely under my radar :( I created #32333 to resolve the problem. @somera and @SoulSeekkor Do you have any condition to do a test for the problem?

GiteaMirror commented

@somera commented on GitHub (Oct 24, 2024):

@lunny I have my 2nd test instance with ~19.000 mirrors. I need then an linux-amd64 executable.

@somera commented on GitHub (Oct 24, 2024): @lunny I have my 2nd test instance with ~19.000 mirrors. I need then an linux-amd64 executable.

GiteaMirror commented

@ckuethe commented on GitHub (Oct 24, 2024):

and I thought I was silly being with 6900 mirrors.

using the docker image...
Version: 1.22.3 Page: 115806ms Template: 181ms

If there's a nighty build or docker image I'm happy to try it

@ckuethe commented on GitHub (Oct 24, 2024): and I thought I was silly being with 6900 mirrors. using the docker image... `Version: 1.22.3 Page: 115806ms Template: 181ms` If there's a nighty build or docker image I'm happy to try it

GiteaMirror commented

https://gitea.com/lunny/packages/src/branch/main/gitea-pr-32333-amd64-linux-1.tar.gz

@lunny commented on GitHub (Oct 24, 2024):

@lunny I have my 2nd test instance with ~19.000 mirrors. I need then an linux-amd64 executable.

@lunny commented on GitHub (Oct 24, 2024): > @lunny I have my 2nd test instance with ~19.000 mirrors. I need then an linux-amd64 executable. https://gitea.com/lunny/packages/src/branch/main/gitea-pr-32333-amd64-linux-1.tar.gz

GiteaMirror commented

@somera commented on GitHub (Oct 24, 2024):

@lunny thx. I try this later today.

@somera commented on GitHub (Oct 24, 2024): @lunny thx. I try this later today.

GiteaMirror commented

@somera commented on GitHub (Oct 24, 2024):

I started it

2024/10/24 19:17:48 cmd/web.go:242:runWeb() [I] Starting Gitea on PID: 9711
2024/10/24 19:17:48 cmd/web.go:111:showWebStartupMessage() [I] Gitea version: 1.22.0+rc1-589-gc72d24a757 built with GNU Make 3.81, go1.23.2 : bindata
2024/10/24 19:17:48 cmd/web.go:112:showWebStartupMessage() [I] * RunMode: prod
2024/10/24 19:17:48 cmd/web.go:113:showWebStartupMessage() [I] * AppPath: /home/git/bin/gitea-pr-32333-amd64-linux
2024/10/24 19:17:48 cmd/web.go:114:showWebStartupMessage() [I] * WorkPath: /var/lib/gitea
2024/10/24 19:17:48 cmd/web.go:115:showWebStartupMessage() [I] * CustomPath: /var/lib/gitea/custom
2024/10/24 19:17:48 cmd/web.go:116:showWebStartupMessage() [I] * ConfigFile: /etc/gitea/app.ini
2024/10/24 19:17:48 cmd/web.go:117:showWebStartupMessage() [I] Prepare to run web server
2024/10/24 19:17:48 routers/init.go:117:InitWebInstalled() [I] Git version: 2.47.0 (home: /var/lib/gitea/data/home)

The new pr version feels fast.

vs

and

vs

and on higher pages

vs

Speedup ist good.

Sorting is the same.

Works for me!

@somera commented on GitHub (Oct 24, 2024): I started it ``` 2024/10/24 19:17:48 cmd/web.go:242:runWeb() [I] Starting Gitea on PID: 9711 2024/10/24 19:17:48 cmd/web.go:111:showWebStartupMessage() [I] Gitea version: 1.22.0+rc1-589-gc72d24a757 built with GNU Make 3.81, go1.23.2 : bindata 2024/10/24 19:17:48 cmd/web.go:112:showWebStartupMessage() [I] * RunMode: prod 2024/10/24 19:17:48 cmd/web.go:113:showWebStartupMessage() [I] * AppPath: /home/git/bin/gitea-pr-32333-amd64-linux 2024/10/24 19:17:48 cmd/web.go:114:showWebStartupMessage() [I] * WorkPath: /var/lib/gitea 2024/10/24 19:17:48 cmd/web.go:115:showWebStartupMessage() [I] * CustomPath: /var/lib/gitea/custom 2024/10/24 19:17:48 cmd/web.go:116:showWebStartupMessage() [I] * ConfigFile: /etc/gitea/app.ini 2024/10/24 19:17:48 cmd/web.go:117:showWebStartupMessage() [I] Prepare to run web server 2024/10/24 19:17:48 routers/init.go:117:InitWebInstalled() [I] Git version: 2.47.0 (home: /var/lib/gitea/data/home) ``` The new pr version feels fast. ![image](https://github.com/user-attachments/assets/04445a1b-2e5f-4f2e-b5f5-fae97f283a1e) vs ![image](https://github.com/user-attachments/assets/052f233f-8c39-4596-b961-05fe2de75f1f) and ![image](https://github.com/user-attachments/assets/81083d50-cf36-4d59-aa6a-a9693cdd94b5) vs ![image](https://github.com/user-attachments/assets/1f86e110-7aee-459a-87de-7aba54ce99f1) and on higher pages ![image](https://github.com/user-attachments/assets/8e7e4526-f353-4a83-8c88-baa1f2fb3ac7) vs ![image](https://github.com/user-attachments/assets/be62ef7f-5391-4242-a80f-2b077789265a) Speedup ist good. Sorting is the same. Works for me!

GiteaMirror commented

@somera commented on GitHub (Oct 24, 2024):

My mistake was: I didn't install 1.22.3 for comparison.

@somera commented on GitHub (Oct 24, 2024): My mistake was: I didn't install 1.22.3 for comparison.

GiteaMirror commented

@ckuethe commented on GitHub (Oct 24, 2024):

2024/10/24 10:59:24 routers/init.go:141:InitWebInstalled() [F] SQLite3 support is disabled, but it is used for database setting. Please get or build a Gitea release with SQLite3 support.

@lunny I just mounted your binary into my docker container

@ckuethe commented on GitHub (Oct 24, 2024): `2024/10/24 10:59:24 routers/init.go:141:InitWebInstalled() [F] SQLite3 support is disabled, but it is used for database setting. Please get or build a Gitea release with SQLite3 support.` @lunny I just mounted your binary into my docker container

GiteaMirror commented

@lunny commented on GitHub (Oct 24, 2024):

2024/10/24 10:59:24 routers/init.go:141:InitWebInstalled() [F] SQLite3 support is disabled, but it is used for database setting. Please get or build a Gitea release with SQLite3 support.

@lunny I just mounted your binary into my docker container

Yes, my binary doesn't support SQLite3 because I compile it in macOS.

@lunny commented on GitHub (Oct 24, 2024): > `2024/10/24 10:59:24 routers/init.go:141:InitWebInstalled() [F] SQLite3 support is disabled, but it is used for database setting. Please get or build a Gitea release with SQLite3 support.` > > @lunny I just mounted your binary into my docker container Yes, my binary doesn't support SQLite3 because I compile it in macOS.

GiteaMirror commented

@somera commented on GitHub (Oct 26, 2024):

My mistake was: I didn't install 1.22.3 for comparison.

Here 1.22.3 results ...

"same" performance like with 1.22.2.

The performance in the https://gitea.com/lunny/packages/src/branch/main/gitea-pr-32333-amd64-linux-1.tar.gz versions is better.

@somera commented on GitHub (Oct 26, 2024): > My mistake was: I didn't install 1.22.3 for comparison. Here 1.22.3 results ... ![image](https://github.com/user-attachments/assets/8beb4e8b-0ddf-4132-9be0-97c4ad4395c3) ![image](https://github.com/user-attachments/assets/9386e739-7956-4ef5-9f6d-725db6bd49cf) ![image](https://github.com/user-attachments/assets/1a013814-2307-4261-9c3f-a950f3c0e211) ![image](https://github.com/user-attachments/assets/96a1cfb0-ab99-4c9c-9155-b946f403336b) ![image](https://github.com/user-attachments/assets/76c4a6fb-c0e3-4fc3-96cc-d8f7d403ab02) "same" performance like with 1.22.2. The performance in the https://gitea.com/lunny/packages/src/branch/main/gitea-pr-32333-amd64-linux-1.tar.gz versions is better.

GiteaMirror commented