Gregory's ServerUpdated mastodon.social to latest code from the master branch. Personally a fan of the new streaming API mechanism that allows the whole UI to use just one connection instead of having to open separate connections for each timeline.
 26 comments
@freemo Eh, it's probably one of those things that help the user more than the server, especially on mobile networks  @Gargron Why is that? I Wouldn't have thought 1 connection vs 5 connections would make much impact, even on a mobile device. Though I am just speculating. @Gargron Fair, I mean, its the design i would go with on those grounds alone. It was good call. Was really just wondering if you saw any noticable impact to M/S resource consumption as a result. But I guess not? @freemo Not really, no. When people have only the home timeline open there's no difference at all. It would make a difference for people who have like 20 hashtag columns pinned in the advanced interface, but those are rare.  @Gargron I was never getting the PWA install prompt. You update and it's just there. My guess was a cache miss on my local device.  @Gargron I'm on Safari and I have to refresh the page often to get new toots. Is there something I can turn on or off to have Mastodon stay up-to-date across all columns? @cdevroe That doesn't sound like something that should normally happen. I don't have access to Safari on desktop, do you know how to check the console for errors? @Gargron There are console errors. But none jump out as particularly bad. The failed resource appears to be an SVG. @cdevroe Is there a network requests tab where you could see requests to /api/v1/streaming? @cdevroe So seems like a connection is at least being made! If you click on it, do you get information about messages sent through the connection? @Gargron Looks like it has a few tabs. Preview shows the JSON stream, Headers, Cookies, Sizes, Timing and Security. That all seems to be working at the moment. My bet is that if I leave this pinned tab for some amount of time, Safari will eventually "shut it off" @cdevroe If that's the case, I wouldn't know what to do about it. If the websocket connection fails, there's a retry mechanism, plus a polling fallback. If the browser kills the page so none of that happens that's outside my expertise 😦 @cdevroe But yeah in the JSON stream you'll likely see events like "subscribe" and "unsubscribe". If there's no "subscribe" event or an unexpected "unsubscribe" event then it could be another reason why you might not receive any new toots. @Gargron Following up on this thread, this morning I got this message even though my computer was plugged in: @Gargron I wouldn't expect you to be able to fix that, that's for sure! It appears that Webkit - and other browsers - have a feature called background tab throttling. One Chrome et. al you can shut it off. But Safari doesn't have a preference for that unless you use a preference rewrite via Terminal. If I come across anything that will help keep Mastodon alive even if Safari tries to kill the connection I'll update this thread. @Gargron I believe it may be an issue where Safari kills the page when I have it in a tab for an extended period. I keep Mastodon in a pinned tab in Safari for weeks at a time. @Gargron What the possibilities to fix, for a hub administrator? ;) |
@Gargron for a lot of users that sounds like an improvement.. Though it would take a lot of connections to have much of an effect.
Do you see a performance increase on M.S?