Nothing4You

stating that it's an issue on our end as our server isn't keeping up

this isn't exactly an issue in your end, unless you consider hosting the server in Australia as your issue. the problem is the latency across the world and lemmy not sending multiple activities simultaneously. there is nothing LW can do about this. as unfortunate as it is, the "best" solution at the time would be moving the server to Europe.

there are still some options besides moving the server entirely though. if you can get the activities to lemmy without as many delays am experience similar to being hosted in Europe can be achieved.

aussie.zone is just not keeping up with the amount of activities generated on lemmy.world.

it's not going lower than a week anymore without actively doing something to improve this situation, and once a week all activities older than a week that haven't been received from LW yet will be discarded on LWs end.

this is most likely mostly caused by latency from LW (finland) to aussie.zone, as lemmy only sends one activity at a time, requiring a round trip across the world for every single activity activity before sending the next one.

there are a couple things that can cause comments to show up on aussie.zone before they would regularly federate, such as someone searching the post/comment url on aussie.zone. some clients will do this automatically if you click a link to a post/comment from another instance.

lemmy currently only sends one activity per receiving instance at a time, so there is a round trip for every single post, comment, vote, etc., before the next activity will be sent. you wouldn't see any increased number of connections, as there's only a single one.

do you have access logs for /inbox with the lemmy.world's user agent? you might be able to derive some information from that if requests increased over time or something, maybe also response status codes?

I can't tell you why you're lagging but you're clearly lagging quite a bit behind.

which country is your instance located in?
did you (or someone else on your instance) recently subscribe to a bunch of high traffic communities on lemmy.world, which would make lemmy.world send more activities to you?

lemmy by default only sends activities in a community to another instance if there's at least one subscriber to the community on that instance. if you're located far from finland, where lemmy.world is located, you might have been able to keep up just enough before this, although this isn't the first time as the graphs above show.

ah i was misreading your comment, i thought you were talking about the sending side. for the receiving side i agree, but the reason for the duplicate activities is yet to be found: https://github.com/LemmyNet/lemmy/issues/4609

records can't be duplicated in the database, the activity id is a unique key:

lemmy=# \d sent_activity
                                               Table "public.sent_activity"
           Column            |           Type           | Collation | Nullable |                  Default
-----------------------------+--------------------------+-----------+----------+-------------------------------------------
 id                          | bigint                   |           | not null | nextval('sent_activity_id_seq'::regclass)
 ap_id                       | text                     |           | not null |
 data                        | json                     |           | not null |
 sensitive                   | boolean                  |           | not null |
 published                   | timestamp with time zone |           | not null | now()
 send_inboxes                | text[]                   |           | not null |
 send_community_followers_of | integer                  |           |          |
 send_all_instances          | boolean                  |           | not null |
 actor_type                  | actor_type_enum          |           | not null |
 actor_apub_id               | text                     |           |          |
Indexes:
    "sent_activity_pkey" PRIMARY KEY, btree (id)
    "sent_activity_ap_id_key" UNIQUE CONSTRAINT, btree (ap_id)