Oh shit does lemmy not have response caching? Yeah, that's gonna be an issue pretty soon.
tortoise
hh3tf.golden.exe is 1536 bytes, compiled from C, and comes with a comma and exclamation point:
I'm actually surprised it's that large, but Windows gonna Windows.
I wonder if YouTube still uses Python to this day
We do not.
One more anecdote for y'all to pluralize into data: my instance is currently using 915Mi of storage for pictrs and 976Mi for postgres, roughly 650Mi of RAM (including postgres), and negligible CPU
My other reason is that it's the only way to know I picked an instance that isn't going to just go away without me and take my account with it. It will be an interesting day when the first major lemmy instance goes down...
Confirmed that I am able to comment on that thread if I manually set the comment language to English, but leaving it as the default "Select language" makes it spin forever.
Not relevant to lemmy (yet), but this does break down a bit at very large scales. (Source: am infra eng at YouTube.)
System architecture (particularly storage) is certainly by far the largest contributor to web performance, but the language of choice and its execution environment can matter. It's not so important when it's the difference between using 51% and 50% of some server's CPU or serving requests in 101 vs 100 ms, but when it's the difference between running 5100 and 5000 servers or blocking threads for 101 vs 100 CPU-hours per second, you'll feel it.
Languages also build up cultures and ecosystems surrounding them that can lend themselves to certain architectural decisions that might not be beneficial. I think one of the major reasons they migrated the YouTube backend from Python to C++ isn't really anything to do with the core languages themselves, but the fact that existing C++ libraries tend to be way more optimized than their Python equivalents, so we wouldn't have to invest as much in developing more efficient libraries.
lol, my bad. i replied from the wrong account and tried to delete it and do it again but I guess it didn't delete the first one fully
I was thinking about writing a script that just fetches the community lists from some popular instances then searches them on mine...
I moved my .dev to NameSilo to live with the rest of my domains, since luckily that's allowed now. See here for the list of options if you have any Google Registry domains (.dev, .app, .new, etc.). Make sure to uncheck "Show preferred partners only" if you don't care which ones have given Google more money or whatever that means.
FWIW the comms I've seen suggest Squarespace has agreed to actually offer standalone domains as part of this deal... I doubt that's binding in the long term though, and they'll certainly want to get people to use their signature site builder product.
I know Google Cloud Domains (previously separate from Google Domains) is being deprecated too, but I don't know if those domains are also automatically moving to Squarespace. Seems weird if they do that, since it would drive people directly to one of Cloud's main competitors... but they're driving people away from Cloud anyway with this so ¯\_(ツ)_/¯
I imagine the ones the middle managers use internally are safe.. that is, the main Workspace apps (I think that's what they're called now? you know... Docs, Sheets, Forms, Slides, Calendar, Chat).
And the few Cloud services that are actually running things like YouTube (Spanner, ... actually I think that's the only publicly available one)
Ehhhhhhh. Using a relational database for Lemmy was certainly a choice, but I don't think it's necessarily a bad one.
Within Lemmy, by far the most expensive part of the database is going to be comment trees, and within the industry the consensus on the best database structure to represent these is... well, there isn't one. The efficiency of this depends way more on how you implement it within a given database model than on the database model itself. Comment trees are actually a pretty difficult problem; you'll notice a lot of platforms have limits on comment depth, and there's a reason for that. Getting just one level of replies to work efficiently can be tricky, regardless of the choice of DBMS.
Looking at the schema Lemmy uses, I see a couple opportunities to optimize it down the road. One of the first things I noticed is that comment replies don't seem to be directly related back to the top-level post, meaning you're restricted to a breadth-first search of the comment tree at serving time. Most comments will be at pretty shallow depths, so it sometimes makes sense to flatten the first few levels of this structure so you can get most relevant comments in a single query and rebuild the tree post-fetching. But this makes nomination (i.e. getting the "top 100" or whatever comments to show on your page) a lot more difficult, so it makes sense that it's currently written the way it is.
If it's true (as another commenter said) that there's no response caching for comment queries, that's a much bigger opportunity for optimization than anything else in the database.