Like does content get mirrored to my instance and then mine distributes it ala BitTorrent or is my instance it’s own thing?

  • Rikudou_Sage@lemmings.world
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    2
    ·
    1 year ago

    They’ll do it once, though. Then every time you view it, you’re helping the bigger servers by serving it from your instance.

    • sab@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 year ago

      Yes. Once for every post, comment and vote.

      So say you have your own personal instance, and you use that to follow community news on lemmy.world. If throughout the day that community receives 10 new topics, 50 comments and 100 upvotes, it would have to make 160 calls to your server.

      So when you decide to read those 10 topics (if you even read all of them), you would then make roughly 10 api calls.

      You would be saving those last mentioned 10 calls by using your own instance, but at the cost of 160 calls made throughout the day.

      • Rikudou_Sage@lemmings.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 year ago

        So you need just 15 more users on your instance to break even, if you have 17 in total, you’ve saved 10 calls.

        • sab@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 year ago

          So you need just 15 more users on your instance to break even, if you have 17 in total, you’ve saved 10 calls.

          In this particular example, yes. But only if those 15 people subscribe to the exact same communities. If they don’t, the calculation gets even more complicated.

          I’m not sure why exactly you’re opposed to federation when that’s one of the biggest points of fediverse.

          Some people seem to be under the impression that setting up their own personal server is relieving the pressure on the network. What I trying to get across is that’s not the case, unless it’s being used by a reasonable amount of people.

          I can’t tell you what the sweet spot is - but my guess would be that it’s only going to be at least several dozen, more if their interests (subscriptions) don’t overlap very well.

      • ashe@lemmy.starless.one
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        The thing is that when you interact with the remote server directly it’s not 10 api calls, it’s 10 full-blown HTML webpages that have to be served to you, which are way bigger than REST API calls.

        • sab@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 year ago

          Generally speaking, lemmy is much more cpu bound than it is bound by bandwidth - so the added bytes don’t matter that much. The example above was just for 1 community. Now imagine the user is subscribed to a dozen communities, but doesn’t even browse lemmy that day. That’s probably thousands of api calls made to keep his server on sync, and 0 requests saved.

          Like the big instances have literally hundreds of thousands of workers running in order to get all the updates out. If one of those calls fails, it gets put back into the queue for retry.

          OP asked if having his server added to the lemmiverse would alleviate the load “Like with torrent”. That is demonstrably not the case - it only adds more workload on the other servers, with a break even point that’s highly variable. Yes, your server will be nice and snappy, but the origin servers have to pay the price - death by a thousand papercuts synchronisation calls.

          • ashe@lemmy.starless.one
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            1 year ago

            Yeah you’re right, I just felt the need to point out that API calls are not really comparable to serving a full website.