Are internal REST requests truly non-blocking?

  • This topic has 2 replies, 1 voice, and was last updated 2 months ago by mikepun-locol.
Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #2263

    I have an API I’m building that utilizes WP Background Processing to run through about 2000,000 API requests per day.

    It works well but order for the tasks to not take long I’m trying to put some routines into async /non-blocking rest requests (using POST).

    My timing on calling this subroutine via REST requests seems to sometimes vary, almost as if it sometimes processes the function at the endpoint before returning.

    I can’t figure out what else could make calling a rest route vary by 2 seconds sometimes.

    Any insight would be super appreciated.



    That depends on your architecture and exactly how you coded the calls.

    Are you running both sides on the same server? Your processing might be pre emting each other. If you are handling that many calls, you are in pretty good shape anyway.

    Can you put up a service mesh to see what’s going on? We use linkerd to track latency cause on K8s that’s really easy to use but there are others.


    I am going to guess that your process is already non blocking, in the sense that a thread is not blocking the processor from other threads. What you are referring to, seem to be the latency of the restful call, and how async is the call.

    So if the endpoint processes the business logic before returning a response, and your code is waiting for the response, then the whole process is not really async. The endpoint should return a 200 right away and then do the processing to be truly async.

    If you are already doing that, then I suspect it’s just a matter of being preempted.

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.