Hi,We're thinking about using prefect for writing our "Flows".
For very large workloads, we're looking for a distributed solution and we're so happy that prefect has such a smooth integration with dask. 😃However, we also have workloads that are extremely light and require sub-second latency. We performed some benchmarks internally and realized that compared to bare-metal python, prefect has an overhead of about 50ms - which is okay for us.But, we were thinking that as prefect grows, is there a possibility that perhaps this overhead would grow too big (in seconds)?Ultimately, this is more of a question regarding the prefect philosophy. Is prefect going to concentrate only on large workloads that require throughput while sacrificing the latency for small workloads? Or, is it going to keep a balance between both worlds?Thanks!
8 months ago
Hi @Rehan Razzaque Rajput, current Prefect core is stabilized so that overhead should be relatively fixed. We’re always looking to decrease overhead and will continue to explore doing so with Orion (Prefect 2.0). There will always be some overhead because of the observability added, but with Orion, streaming workloads are also being considered
Exactly! I was extremely happy to see Orion! When I get more time, I'll try to play around with it too!Thank you so much for your quick answer, and kudos to all of you for creating such a great product!
As a follow-up, could you elaborate more on what you mean by "observability" here? is it possible for us to disable it and still use prefect-core?Note that we're not using Prefect Cloud OR Prefect Server.
8 months ago
So a task hits the API to update state. Each task has at least 3 state transitions (Scheduled, Submitted, Running, Success). So that is where the overhead comes from. In Orion though, not everything needs to be a task, meaning that you can have regular Python mixed with tasks when you want. You can choose to attach this observability whenever needed