TimoMoss
Hello, in our Phoenix API, we’re making numerous calls to external APIs like Opena Ai, with long responses that can take 2 to 15 seconds.
As an HTTP client, we use Req {:req, "~> 0.5.2"}, when the number of user requests to our API reaches approximately 20 per second, hence the same number of calls we’re doing to the external API we’re getting the following error: (RuntimeError) Finch was unable to provide a connection within the timeout due to excess queuing for connections. Consider adjusting the pool size, count, timeout, or reducing the rate of requests if it is possible that the downstream service is unable to keep up with the current rate.
I played with Finch opts, in the Application supervision children:
children = [
{Finch,
name: MyConfiguredFinch,
pools: %{
:default => [
size: 1000,
count: 200,
pool_max_idle_time: 120_000,
conn_max_idle_time: 120_000
]
}},
....
]
but seems it doesn’t help
I would highly appreciate any help since this happening in the production
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
oliveiragahenrique
Can you confirm that the upstream service is healthy and capable of handling your load?
Keep in mind that Finch connections are lazy—they only initiate new connections when needed. If the upstream service is degraded at that time, try to open a new connection may result in a timeout.
TimoMoss
may I please clarify by the upstream service you mean the external API to which Req makes requests? If so, yes time to time they can respond with 429 but not that often. from 1200 requests per minute only 600 were handled, for all others I got the mentioned above error.
Is there a way to make connections eager?
oliveiragahenrique
Yes! I was referring to the external API that Req makes requests to.
Given the occasional 429 responses, it seems likely the issue is related to the service being unable to establish a new connection when Finch requires a new one (due to lazy initialization).
To confirm, you could try lowering the pool size and pool count (perhaps even setting it to 1) and see if the error persists. If this is indeed the issue, you’ll likely see timeouts, but the connection pool should remain functional and not raise this error.
TimoMoss
Thank you very much Gabriel
Is the following setup correct in general? And also pull size 1, does it slow down the performance?
oliveiragahenrique
Seems correct! But it for sure slow down the performance and the way it is right now it would apply for all services called by this
MyConfiguredFinchinstance.So, I would suggest 2 things:
Somehting like this:
TimoMoss
It helped but not totally, less but still getting the same error, is there buy chance a way to catch this particular error? I can see only
RuntimeErrorwithout any additional markersoliveiragahenrique
You could probaly match on it’s message on a
catch/2My suggestion now would be increasing
:pool_timeoutoption on Finch request. See Finch — Finch v0.23.0Since some of your requests take a long time (eg. 15 seconds) you may end up starving the pool.
One way to measure it is to start pool metrics on finch with the option
:start_pool_metrics?on Finch start_link. See Finch — Finch v0.23.0And then run a periodically job that will execute
Finch.pool_status/2and gather this metrics so you can check if your pool is starving or not.