Conversation

Notices

1. Cat poni, lgbt feminist drag nato demon (pony@blovice.bahnhof.cz)'s status on Wednesday, 06-Dec-2023 02:46:54 JST Cat poni, lgbt feminist drag nato demon
   ok, questions raised
   
   (for example why it can take second and half to do POST on /inbox, like, pls)
   • LS (lain@lain.com)'s status on Wednesday, 06-Dec-2023 02:46:48 JST LS

     in reply to

     • feld
     @feld @pony i think the only part can actually take some time here is:
     
     User.get_or_fetch_by_ap_id(params["actor"])
     
     because that potentially fetches. So maybe this is a bug, where you have something like a deactivated / blocked user, it tries to fetch them every time and just takes long. We should probably do literally nothing in this controller function though and just throw the stuff into the queue, that would prevent problems with /inbox taking long-ish.
   • feld (feld@bikeshed.party)'s status on Wednesday, 06-Dec-2023 02:46:49 JST feld

     in reply to

     • LS
     • feld
     @lain am I wrong about this? ^^^
     
     @pony
   • feld (feld@bikeshed.party)'s status on Wednesday, 06-Dec-2023 02:46:50 JST feld

     in reply to

     • feld
     @pony actually that incoming_ap_doc function drops the activity into an Oban queue anyway
     
     I think this should be reworked to reduce the processing here. We're doing all of this validation just to drop the raw data into an Oban job. Why not just accept any well-formed content posted to the Inbox and let the Oban job handle the rest?
     
     If you get spammed with 1000 posts of garbage it's going to increase the load of your system by doing all this validation concurrently instead of just doing it at the limit of concurrent Oban workers for the incoming queue
   • feld (feld@bikeshed.party)'s status on Wednesday, 06-Dec-2023 02:46:51 JST feld

     in reply to

     @pony

     lib/pleroma/web/activity_pub/activity_pub_controller.ex

     def inbox(%{assigns: %{valid_signature: true}} = conn, %{"nickname" => nickname} = params) do with %User{} = recipient <- User.get_cached_by_nickname(nickname), {:ok, %User{} = actor} <- User.get_or_fetch_by_ap_id(params["actor"]), true <- Utils.recipient_in_message(recipient, actor, params), params <- Utils.maybe_splice_recipient(recipient.ap_id, params) do Federator.incoming_ap_doc(params) json(conn, "ok") end end

     That should be quick, but I'm wondering if the Federator.incoming_ap_doc(params) function is slow? and also we're not doing anything with results from it, so it could be changed to be non-blocking by wrapping it in a Task.start

     I'd be curious to know if your instrumentation shows it's significantly faster if you change that line to:

     Task.start(fn -> Federator.incoming_ap_doc(params) end)

   • Cat poni, lgbt feminist drag nato demon (pony@blovice.bahnhof.cz)'s status on Wednesday, 06-Dec-2023 02:46:52 JST Cat poni, lgbt feminist drag nato demon

     in reply to

     • feld
     @feld incoming, i would like to see inside outgoing stuff workers too, but i don't have that instrumentation (yet)
   • feld (feld@bikeshed.party)'s status on Wednesday, 06-Dec-2023 02:46:53 JST feld

     in reply to
     @pony doing a POST to someone else's server, or a POST coming in to an inbox on your server?
   • feld (feld@bikeshed.party)'s status on Wednesday, 06-Dec-2023 04:02:32 JST feld

     in reply to

     • LS
     • feld
     @lain @pony oookay, running this on my instance now
     
     
     
     https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3985
     LS likes this.
   • feld (feld@bikeshed.party)'s status on Wednesday, 06-Dec-2023 04:02:33 JST feld

     in reply to

     • LS
     @lain @pony yep that's what I was thinking too. All of this work can be moved into the Oban worker.
     
     I'll make a patch and test it