/api/v1/notifications intermitent long request (10s)

neville · 23 May 2025 13:25

Hello,

First thank a lot for Vikunja, it’s a very good tool that i like a lot.

lately, i have an issue i tried to fix (because it ruining user experience a bit), but i was not able to find a solution yet, here is a log to explain :

2025-05-23T13:17:13.6515694Z: INFO      ▶ [DATABASE] 96f [SQL] SELECT "id", "notifiable_id", "notification", "name", "subject_id", "read_at", "created" FROM "notifications" WHERE (notifiable_id = $1) ORDER BY id DESC LIMIT 50 [1] - 842.3µs
2025-05-23T13:17:13.6571205Z: INFO      ▶ [DATABASE] 970 [SQL] SELECT count(*) FROM "notifications" WHERE (notifiable_id = $1) [1] - 860µs
2025-05-23T13:17:13Z: WEB       ▶ 185.43.244.189  GET 200 /api/v1/notifications?page=1 11.6275ms - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
2025-05-23T13:17:17.5753719Z: INFO      ▶ [DATABASE] 971 [SQL] SELECT "id", "notifiable_id", "notification", "name", "subject_id", "read_at", "created" FROM "notifications" WHERE (notifiable_id = $1) ORDER BY id DESC LIMIT 50 [2] - 710.3µs
2025-05-23T13:17:17.576343Z: INFO       ▶ [DATABASE] 972 [SQL] SELECT count(*) FROM "notifications" WHERE (notifiable_id = $1) [2]
2025-05-23T13:17:17Z: WEB       ▶ 185.43.244.189  GET 200 /api/v1/notifications?page=1 3.7635ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:138.0) Gecko/20100101 Firefox/138.0
2025-05-23T13:17:33.6869459Z: INFO      ▶ [DATABASE] 973 [SQL] SELECT "id", "notifiable_id", "notification", "name", "subject_id", "read_at", "created" FROM "notifications" WHERE (notifiable_id = $1) ORDER BY id DESC LIMIT 50 [1] - 10.0386745s
2025-05-23T13:17:33.6971134Z: INFO      ▶ [DATABASE] 974 [SQL] SELECT "id", "notifiable_id", "notification", "name", "subject_id", "read_at", "created" FROM "notifications" WHERE (notifiable_id = $1) ORDER BY id DESC LIMIT 50 [2] - 5.8714787s
2025-05-23T13:17:36.2629158Z: INFO      ▶ [DATABASE] 975 [SQL] SELECT count(*) FROM "notifications" WHERE (notifiable_id = $1) [1] - 2.8882ms
2025-05-23T13:17:36.265386Z: INFO       ▶ [DATABASE] 976 [SQL] SELECT count(*) FROM "notifications" WHERE (notifiable_id = $1) [2] - 1.5705ms
2025-05-23T13:17:36Z: WEB       ▶ 185.43.244.189  GET 200 /api/v1/notifications?page=1 8.4407452s - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:138.0) Gecko/20100101 Firefox/138.0
2025-05-23T13:17:36Z: WEB       ▶ 185.43.244.189  GET 200 /api/v1/notifications?page=1 12.6190799s - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
2025-05-23T13:17:36.2956963Z: INFO      ▶ [DATABASE] 977 [SQL] SELECT "id", "notifiable_id", "notification", "name", "subject_id", "read_at", "created" FROM "notifications" WHERE (notifiable_id = $1) ORDER BY id DESC LIMIT 50 [1] - 773.8µs
2025-05-23T13:17:36.2998111Z: INFO      ▶ [DATABASE] 978 [SQL] SELECT count(*) FROM "notifications" WHERE (notifiable_id = $1) [1] - 964.8µs
2025-05-23T13:17:36Z: WEB       ▶ 185.43.244.189  GET 200 /api/v1/notifications?page=1 7.1084ms - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
2025-05-23T13:17:37.7128608Z: INFO      ▶ [DATABASE] 979 [SQL] SELECT "id", "notifiable_id", "notification", "name", "subject_id", "read_at", "created" FROM "notifications" WHERE (notifiable_id = $1) ORDER BY id DESC LIMIT 50 [2] - 757.4µs
2025-05-23T13:17:37.7141605Z: INFO      ▶ [DATABASE] 97a [SQL] SELECT count(*) FROM "notifications" WHERE (notifiable_id = $1) [2] - 252.4µs
2025-05-23T13:17:37Z: WEB       ▶ 185.43.244.189  GET 200 /api/v1/notifications?page=1 9.9293ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:138.0) Gecko/20100101 Firefox/138.0
2025-05-23T13:17:43.6556101Z: INFO      ▶ [DATABASE] 97b [SQL] SELECT "id", "notifiable_id", "notification", "name", "subject_id", "read_at", "created" FROM "notifications" WHERE (notifiable_id = $1) ORDER BY id DESC LIMIT 50 [1] - 747.1µs
2025-05-23T13:17:43.6591528Z: INFO      ▶ [DATABASE] 97c [SQL] SELECT count(*) FROM "notifications" WHERE (notifiable_id = $1) [1]
2025-05-23T13:17:43Z: WEB       ▶ 185.43.244.189  GET 200 /api/v1/notifications?page=1 8.6882ms - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
2025-05-23T13:17:57.7752204Z: INFO      ▶ [DATABASE] 97d [SQL] SELECT "id", "notifiable_id", "notification", "name", "subject_id", "read_at", "created" FROM "notifications" WHERE (notifiable_id = $1) ORDER BY id DESC LIMIT 50 [2] - 10.0488239s
2025-05-23T13:17:57.7790642Z: INFO      ▶ [DATABASE] 97e [SQL] SELECT "id", "notifiable_id", "notification", "name", "subject_id", "read_at", "created" FROM "notifications" WHERE (notifiable_id = $1) ORDER BY id DESC LIMIT 50 [2] - 58.3204ms
2025-05-23T13:17:57.7822096Z: INFO      ▶ [DATABASE] 980 [SQL] SELECT count(*) FROM "notifications" WHERE (notifiable_id = $1) [2] - 2.4746ms
2025-05-23T13:17:57.7790642Z: INFO      ▶ [DATABASE] 97f [SQL] SELECT "id", "notifiable_id", "notification", "name", "subject_id", "read_at", "created" FROM "notifications" WHERE (notifiable_id = $1) ORDER BY id DESC LIMIT 50 [1] - 4.1284358s
2025-05-23T13:17:57.7832494Z: INFO      ▶ [DATABASE] 981 [SQL] SELECT count(*) FROM "notifications" WHERE (notifiable_id = $1) [2] - 1.0397ms
2025-05-23T13:17:57Z: WEB       ▶ 185.43.244.189  GET 200 /api/v1/notifications?page=1 10.057257s - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:138.0) Gecko/20100101 Firefox/138.0
2025-05-23T13:17:57.787135Z: INFO       ▶ [DATABASE] 982 [SQL] SELECT count(*) FROM "notifications" WHERE (notifiable_id = $1) [1] - 915.1µs
2025-05-23T13:17:57Z: WEB       ▶ 185.43.244.189  GET 200 /api/v1/notifications?page=1 67.4156ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:138.0) Gecko/20100101 Firefox/138.0
2025-05-23T13:17:57Z: WEB       ▶ 185.43.244.189  GET 200 /api/v1/notifications?page=1 4.13947s - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36

i don’t understand why the same call is sometimes less than 10ms and sometimes more than 10 seconds. Vikunja runs with postgres and redis on a windows server.

I’m available if i can provide any more details on my installation.

kolaente · 23 May 2025 14:45

This is probably a Postgres issue, maybe unrelated to Vikunja.

I’ve asked Claude about this and it suggested this could be a hardware problem, coupled with a cache miss. What are you hosting Vikunja on?

neville · 26 May 2025 11:57

Hello, thanks a lot for your response.

It’s a VPS (dual core, 12GB ram) on Windows Server 2022 Datacenter 21H2 .

I did not see anything weird in the reporting, but you were right, after a scheduled reboot to apply windows update all the issue are gone. Notification call are all under 80ms now.

Thanks a lot for your response and sorry for the inconvenience

Topic		Replies	Views
Need help optimizing Vikunja performance - Slow API responses Support	3	93	24 August 2024
Intermittent 60-second API response times Support	5	31	6 March 2025
How to set up Vikunja on Cloudflare Tunnel Support	17	983	6 July 2022
Long time, regular main user being asked to Confirm Email Address Support	10	948	7 May 2021
File upload creates files multiple times Bug	10	412	7 October 2022

/api/v1/notifications intermitent long request (10s)

Related topics