A single Like is measuring as taking significant time on the PostgreSQL database as a INSERT, and comments and postings are even higher. As in 1/2 second of real-time for each and every one.

The lemmy_server code that does https outbound pushes is also not thoughtful about how 20 likes against the same server hosting the community is triggering 20 simultaneous network and database connections… concurrent activity isn’t considered in the queuing from how I read the current 0.17.4 code, and it blindly starts going into timing loops without considering that the same target server has too much activity.

  • RoundSparrowOPM
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year ago

    'major social event’s, such as an airplane crash, terrorist bombing, unexpected death of someone very famous, etc, etc is likely going to cause major problems for all the major Lemmy instances.

    Almost all social media sites have had to deal with scaling issues when people flock to discuss something big.

    I remember 9/11/2001 when Fark.com was the one of the few link aggregator code that held up, pre Twitter, pre Facebook, pre Reddit. https://www.fark.com/comments/45086 (Fark didn’t have voting/like transactions)

    I also have concerns that the Federation protocols are not hardened and prepared for deliberate denial of service and mass spamming. e-mail systems and Reddit-like systems all had to go through major work to harden and deal with these problems. Rate limiting in the code now is very primitive solution. Even 9 years ago when Reddit was an active open source project on GitHub, the owners of Reddit did not share their anti-spam code.