You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This works fine for single process but for multiprocess support the current offered solution makes use of redis & the MultiProcessRedisBackend implementation makes use of the synchronous redis library.
So for supporting multiprocess in an async environment we could offer an async interface of the library like an async def generate_metrics & also an async redis backend implementation AsyncMultiProcessRedisBackend that would require another dependency on an async redis library.
I feel like all that work is not worth it, having to support duplicated behaviour means duplicated effort and might cause confusion. It also adds the number of dependencies required.
I had an idea on implementing a backend in Rust that could work in both sync & async python so that the interface could stay the same. This also can remove the dependency on the redis library if it becomes the defacto standard for multiprocessing.
Not everything is perfect, in an async framework like FastAPI the /metrics endpoint needs to be run in a ThreadPool ideally (a def endpoint would do that automatically) but it's a great start. On the plus side that part can release the GIL so that other threads can work while the metrics get generated!
For supporting async python initial changes where merged for decorators & context managers:
This works fine for single process but for multiprocess support the current offered solution makes use of redis & the
MultiProcessRedisBackend
implementation makes use of the synchronous redis library.So for supporting multiprocess in an async environment we could offer an
async
interface of the library like anasync def generate_metrics
& also an async redis backend implementationAsyncMultiProcessRedisBackend
that would require another dependency on an async redis library.I feel like all that work is not worth it, having to support duplicated behaviour means duplicated effort and might cause confusion. It also adds the number of dependencies required.
I had an idea on implementing a backend in Rust that could work in both
sync
&async
python so that the interface could stay the same. This also can remove the dependency on theredis
library if it becomes the defacto standard for multiprocessing.Not everything is perfect, in an async framework like
FastAPI
the/metrics
endpoint needs to be run in aThreadPool
ideally (adef
endpoint would do that automatically) but it's a great start. On the plus side that part can release theGIL
so that other threads can work while the metrics get generated!The implementation can be followed in here:
The text was updated successfully, but these errors were encountered: