I noticed pages were taking a bit longer than expected to load, so I ended up upgrading to a new server. It already seems faster (and let’s hope it stays that way too). As always, let me know if you notice any peculiarities that might have been caused by the upgrade.
@jwr1@kbin.earth I’m a PHP developer and was following the Kbin project drama for a few months before learning about the MBin fork. I was hesitant to get involved since it wasn’t clear Mbin would continue if Kbin collapsed and Earnest disappeared.
6+ months later, Mbin is still going strong and appears to be getting better with each release.
I’ve quit using all walled garden, billionaire owned social recently so I’ve been spending more time on Mbin instances and other ActivityPub services. The increase in activity is noticeable.
How’s the stability of mbin these days? I initially came to the Fediverse on kbin.social and was bummed when it went under - lost a lot of my old posts and content. Been kicking around on lemmy, but it’s not quite the same.
I’d like to go back to mbin, but worried about longevity due to instance loss, and it seemed like kbin was struggling to handle traffic. I was kinda curious as to how you feel it’s working as an admin.
I feel like it’s been pretty stable, especially now that there are more developers working on it through Mbin. I’ve been running kbin.earth for over a year and the Mbin developers have been very helpful in resolving any issues I (and other admins) have come across.
Honestly, the worst thing that’s happened to Mbin was the kbin.run instance suddenly shuting down and the admin/developer disappearing out of nowhere, but that could easily happen to any Fediverse instance (Mbin, Lemmy, Mastodon, the software doesn’t matter). And, that was way better than what happened to kbin and kbin.social, where the admin and solo developer went silent, causing kbin itself to dwindle out.
All that to say, Mbin learned from Kbin’s failures and focused on having a group of developers instead of just one main developer (which caused a single point of failure). So, yes, I would indeed consider Mbin stable; just pick a server you believe would stick around for a while, and hopefully, if a server does ever need to shut down, they would at least give a warning in advance (I know I would).
Thanks for the detail! I’ll give it a shot - really miss being able to sub to mastodon users.
i think the stats over at https://mbin.fediverse.observer/list speak for themselves… coming up on the 2 year mark for the top servers with general uptime over 97%. that seems longer and better than kbin ever achieved.
the devs have fixed a huge number of internal issues left over from kbin, and added a ton of features.
one thing we do need as a platform is more users. more users will require admins to thoughtfully construct scaling methods and highlight pain points that might need addressing in code.
running one of these, most of my issues are with latency due to my own self-imposed resource constraints. its pretty solid from my point of view. i cant remember the last time something (service or database issue) took the server/site down. the tech support from the dev team is great.
i spend most of my time contemplating the next scaling steps to allow for more users whereas last year it was more about getting the server stable.
Long story short; we are doing our best :). Mbin development team is still small. But I like to focus on stability a lot in the recent years, and I still am.
Progress is maybe slow but steady, introducing missing features and performance improvements along the way. Maybe it’s good to mention that all developers on Mbin work voluntarily without getting paid. Lemmy developers on the other hand are fully paid by their community and can work full-time on Lemmy. We all do the work next to our main job. Thank you for your understanding.
I’m not an admin, so I’m not qualified to answer that part, but I also came from kbin.social originally. I moved to fedia.io/Mbin when kbin.social and kbin itself died. I’ve definitely had a much better time on Fedia/Mbin as far as stability. I think that probably comes down to several factors:
- the stability of the software itself
- an attentive admin who’s around to kick the tires
- less load on the server/s
For comparison, here’s the last successful capture archive.org made of the kbin.social stats page. It lists 64601 users and 115388 threads. Here’s the present-day fedia.io stats page which as I write this comment is reporting 5132 users and 9629 threads. Naively extrapolating from these figures, kbin.social was apparently taking >10 times the load that the largest Mbin server is currently. On the one hand, it would be nice to see Mbin grow to the heights of early kbin, but the current situation is far more manageable for these mostly out of pocket/donation-supported projects.
I try to help and closely work together with @jerry@infosec.exchange (who is the admin of that instance) a lot to get Mbin as stable as possible. So to glad to hear you notice the end result.
@melroy @jwr1 @arotrios @vaguerant I cannot express how awesome the mbin team has been. I have no idea how kbin.social was able to operate with that many users while running kbin. I can definitely see mbin working for that large of a user base, though.
I have no idea how kbin.social was able to operate with that many users while running kbin.
Where was some custom things doing on for sure. Maybe @piotrsikora@pol.social can recall how they get kbin running at all back in the days with that many users.
@melroy we cache many things on varnish and CDN, and also we do many database optimization, but I think all I send to you.
And of corse many optimization in database configuration, disk optimization, PHP optimization. All best practice that I know I put there.
But if someone need help I can help with that.
My instance rimworld.gallery has been stable ever since mbin was introduced. Sure, it was a bit of a bumpy ride in the beginning, but now it will run for weeks without any trouble. Handling about 100 real visits per day and 1000s through federation, serving big jpgs 5-34MB continuously without a hiccup
I just noticed the API/App had issues with Oauth, but I have just fixed that.
🥳
nice, all looks good so far.
