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
{{ message }}
This repository has been archived by the owner on Mar 31, 2022. It is now read-only.
Since it can take some time for the API to generate the form data, I propose that we generate/buffer responses before a request is received.
A basic producer/consumer pattern should do the trick, where a separate thread/process generates responses and stored them in a shared queue of configurable length n. As long as the queue isn't full, the producer generates responses and adds them to the queue. Whenever a request comes in, the consumer will pop a buffered response and return it to the caller.
The text was updated successfully, but these errors were encountered:
That seems like a pretty good idea. Making the size of the queue configurable via environment variables would also be a good idea I think. That way, if someone is just running it for themselves they can have the queue be fairly small (like 2 to 4 maybe) and if someone is hosting it for other people they can amp it up to meet the number of users for their API server.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Since it can take some time for the API to generate the form data, I propose that we generate/buffer responses before a request is received.
A basic producer/consumer pattern should do the trick, where a separate thread/process generates responses and stored them in a shared queue of configurable length n. As long as the queue isn't full, the producer generates responses and adds them to the queue. Whenever a request comes in, the consumer will pop a buffered response and return it to the caller.
The text was updated successfully, but these errors were encountered: