cheeaun
Notifications slow to load
I'm finding notifications very slow to load (first time in a session) or to refresh.
Looking into it, the request to /api/v1/notifications?limit=80&exclude_types[]=follow_request averages about 3 seconds on my primary instance, and about 1 second on my alt on a different instance. (It's returning about 500kB of data, ~180kB of which is copies of my own profile attached to every reblog and favourite notification.)
Maybe this is a server tuning issue or an inefficient Mastodon API design issue, and maybe server-side batching of notifications will make this better, but... I also wonder why Phanpy requests 80 notifications every time I open the notifications tab. Couldn't it only request the new ones? Also, could the initial set of notifications be requested eagerly when I open Phanpy (Mastodon web does this, so notifs feel faster), and new ones requested in the background as they become available through the streaming API?
- Which site: phanpy.social
- Which site version: 2024.08.08.dabb480
- Which instance: mainly carfree.city
To Reproduce
- Open Phanpy
- Click on profile pic with blue circle in top left
- Click on Notifications
- Wait a long time
Expected behavior Notifications show up pretty fast or immediately
Desktop (please complete the following information):
- OS: Linux
- Browser: Firefox
- Version: 129
I personally would see this as a backend issue, but first, some notes for context:
- 80 is used because that's the max Mastodon allows. It was bumped up at some point on Mastodon's side to enable clients to request more, so I assumed the server could handle it 🫣 (Phanpy is probably not the only client setting it to 80) - This change was done on Phanpy 3 months ago, from 30 to 80 https://github.com/cheeaun/phanpy/commit/025a5429cc1af3a3a4046c5c044be7c42a90cdb5
- 80 is used so that client-side notifications grouping works better. For 1st "page" load, it'll always be 80 instead of prepending "newer" notifications because the grouping is re-rendered (everything is regrouped again) instead of "cut off" at the top. The grouping will only "cut off" for subsequent "next" paginated responses.
- This could probably be solved if Phanpy stores individual notifications in a local DB (like how most native apps work), so there's no "wasted" API calls, but I haven't look into it yet.
If this proves to be an issue for many servers, perhaps we can lower the limit to a reasonable number?
Thanks for the context on why it works as it does. I gather then that the way Phanpy is storing the notifications on the client side now, they're pre-grouped? I like the idea of storing individual notifications in a way that would allow for new ones to be added in piecemeal.
Maybe in that case it would also be practical to load notifications eagerly, before the "page" is viewed? On the faster of the two instances I have accounts on, when Mastodon web requests 40 notifications, it still takes between 500 ms and 1 sec, so it seems like it's going to be a perceptible delay regardless of the limit. Is this much faster on the server(s) you use?
just out of curiosity, any news about this one? Phapny in general is awesome, but I need to constantly refresh notifications on my own to see if there's something new, it's a bit annoying ;)
