I’ve seen many arguments claiming that Lemmy Federate creates a significant load on instances in terms of data storage and networking. I used to believe this wasn’t a very valid concern, as I assumed that communities without followers wouldn’t generate many posts, comments, likes, etc.
Today, I had the chance to test this on my own instance, and here are the results:
- Communities
-
-
-
- Posts
-
-
-
- Comments
-
-
-
LF = Lemmy Federate. Posts and comments refer to the number of posts and comments in communities federated with Lemmy Federate.
As you can see from the statistics, almost 20% of the communities are federated by Lemmy Federate. Although this seems like a high number, only 3.5% of the posts are created in communities federated by Lemmy Federate. The number of comments is even less than the number of posts.
So to answer, Lemmy Federate creates an average load of around 2-3% in an instance with about 1000 users. You can compare it with its benefits and decide whether to use it or not.
If you want to get stats for your own instance, you can run the SQL script below. Let us know the results please :)
the script
-- make sure to replace the <lemmy_federate_bot_person_id>
WITH
-- Total community count
total_communities AS (
SELECT COUNT(id) AS total FROM community where local != true
),
-- Communities federated by LF (assuming person_id <lemmy_federate_bot_person_id> represents LF bot)
-- A community is considered federated by LF if LF follows it and it has local subscribers
lf_communities AS (
SELECT ca.community_id
FROM community_aggregates ca
JOIN community c on c.id = ca.community_id
JOIN community_follower cf ON ca.community_id = cf.community_id
WHERE ca.subscribers_local > 0 and c.local != true AND cf.person_id = <lemmy_federate_bot_person_id>
),
lf_communities_count AS (
SELECT COUNT(*) AS count FROM lf_communities
),
-- Total post count
total_posts AS (
SELECT COUNT(id) AS total FROM post
),
-- Posts in LF communities
lf_posts AS (
SELECT COUNT(p.id) AS count
FROM post p
WHERE p.community_id IN (SELECT community_id FROM lf_communities)
),
-- Total comment count
total_comments AS (
SELECT COUNT(id) AS total FROM comment
),
-- Comments on posts in LF communities
lf_comments AS (
SELECT COUNT(c.id) AS count
FROM comment c
JOIN post p ON c.post_id = p.id
WHERE p.community_id IN (SELECT community_id FROM lf_communities)
)
-- Final output
SELECT
tc.total AS community_count,
lfc.count AS community_count_lf,
ROUND((lfc.count::decimal / tc.total) * 100, 2) AS community_lf_percent,
tp.total AS post_count,
lp.count AS post_count_lf,
ROUND((lp.count::decimal / tp.total) * 100, 2) AS post_lf_percent,
tcom.total AS comment_count,
lcom.count AS comment_count_lf,
ROUND((lcom.count::decimal / tcom.total) * 100, 2) AS comment_lf_percent
FROM total_communities tc
JOIN lf_communities_count lfc ON TRUE
JOIN total_posts tp ON TRUE
JOIN lf_posts lp ON TRUE
JOIN total_comments tcom ON TRUE
JOIN lf_comments lcom ON TRUE;
I think Meilisearch is pretty good. I throw it wherever possible and it works :) Implementing a custom solution is not worth it.