With prefect server and localagent is there any wa...
# ask-community
a
With prefect server and localagent is there any way to limit job execution concurrency? If I get 1000 jobs submitted in one min, but that server can really only handle executing 150 at a time before it falls over, what ways do I have of improving this situation?
k
Hey @Adam Brusselback, unfortunately not. It was explored here and was not performant so the effort was stopped.
a
These are fast executing tasks, so the server can easily get through all 1000 in a full min, but if it tries launching all at once, progress stops. If it launches a reasonable number of them, waits for them to finish, then launches more, we get through that queue of 1000 launched flows nice and quick
Well, shoot
k
It sounds like you can rearchitect this then to be controlled by a “main flow” using LocalDaskExecutor to treat it like a queue?
a
Maybe, these are individual jobs running for each client in my saas. They can be on the default schedule, or an custom schedule
so there isn't a possibility for a main flow I don't believe, as they all need to be independent flows (per-client)
(a client is a project in this instance)
k
I am honestly not seeing another way other than starting up another agent (with different compute backing it). Or Cloud cuz Cloud has flow run concurrency limiting and task run concurrency limiting but these need orchestration background services that are not shipped with server.
Or this might need some other tool other than Prefect to handle these fast jobs like a task queue?
a
Yeah, that was essentially what I was trying to use Prefect to replace, my current job scheduler infrastructure handles these small tasks fine
just running using jpgagent job scheduler, I had implemented some concurrency limits in that years ago though to smooth this type of workload over.
k
The lower-bound of Prefect jobs where it’s still performant is around 1 min or 30 seconds because it’s primarily a batch orchestrator and there is some overhead with the API states.
a
Yeah, a lot of these jobs are going to run for <1 second if it turns out there is nothing to do (the majority of the time), and then will take ~20s-2min if there is work to do
Question, is the localdaskexecutor process/thread limit a global limit for all flows using that same localdaskexecutor object? or is that just for that single flows execution, do not use more than X threads/processes to execute the tasks?
And if so, would setting up an explicit dask cluster be a better way to deal with the concurrency issue?
k
LocalDaskExecutor is a multiprocessing pool so it’s the “do not use more than X threads/processes to execute the tasks”.
In my opinion, using LocalDaskExecutor where each of those Flows are not Tasks should be smoother than the Dask executor because that implies you have a remote cluster and are sending work which would be even more overhead