Software engineer and collector of expensive hobbies.

I was /u/TortoiseWrath but then reddit imploded.

  • 1 Post
  • 21 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle



  • 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.










  • 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 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.




  • 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 ¯\_(ツ)_/¯





  • If you can read this, the Ansible playbook mostly Just Worked™ to install it on a clean Debian VPS. I actually did start over at one point because I wanted to change the domain name after learning there’s not currently any way to use different domains for the UI and usernames like there is in Mastodon (relevant github issue); from that, I suspect it should be good about not clobbering anything except maybe SSL certs for existing nginx sites.

    For some reason, my nginx also now seems to try to use the cert lemmy installed by default, even on a site I just set up to only listen on port 80 (http://gillen.dev). So that’s kinda weird, but just installing a new cert for such a site with certbot fixes it (https://sdg.fyi).

    It still seems to be struggling a little bit: votes and comments on this thread are taking a looong time to show up here (your comment just got here and it says it was from 24 minutes ago)… or maybe I’m just impatient :)

    Of course, the real test will be when it comes time to update to the next Lemmy version…