agacode
Hi Guys,
I’m have a performance issue after an elixir upgrade:
before:
elixir 1.6.4
erlang 20.3
phoenix 1.3.2
now:
elixir 1.9.0
erlang 22.0.4
phoenix 1.4.10
2000 requests/sec, 100 DB Connections (Postgres)
Before the 2000 requests executed in about 4 - 5 min, but the average time for each request was like 6s (I know this number is high and I need to cache some results to lower the request execution time, but that is not the problem I’m facing)
After the upgrade the total time is less about 2 - 3 min, but the average time for each request is 40s. It was a surprise to me that the new Elixir with the same settings as before was performing worse, even more, I’m losing some requests the HAProxy (working as reverse proxy) shows 2000 and my elixir backend app shows 1600. I even had to tweak some configuration values (to be able to finish most of the request) that I didn’t have to tweak before.
When I look at the logs locally, I see that the DBConnection Pool is switching too much between request and it is trying to execute close to 1 query on each request. So, it means that I have close to 2000 request executing little by little (I think because of this new CoDel alg). I would prefer to use a setting (If there was one) to assign a DBConnection to a request till the request finishes executing. I was looking also into DBConnection.Ownership to play with the :ownership_timeout but I also read that DBConnection.Ownership is more for tests (might have misinterpreted this)
My current settings:
config :myapp, BeaconWeb.Endpoint,
http: [
...
protocol_options: [
idle_timeout: 1_200_000,
inactivity_timeout: 1_200_000
]
]
config :myapp, Beacon.Repo,
...
pool_size: 100,
timeout: 100_000_000,
queue_target: 100_000_000
As additional information I’m getting this message frequently on localhost:
With DBConnection.ConnectionPool:
[info] [] Postgrex.Protocol (#PID<0.2384.0>) disconnected: ** (DBConnection.ConnectionError) client #PID<0.4135.0> exited
With DBConnection.Ownership:
[error] [] Postgrex.Protocol (#PID<0.2384.0>) disconnected: ** (DBConnection.ConnectionError) client #PID<0.4135.0> exited
Documentation I have checked:
https://ninenines.eu/docs/en/cowboy/2.5/manual/cowboy_http/
Any help will be appreciated. Thanks in advance.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance










First 10 of 16 Posts
benwilson512
You can do so explicitly via:
agacode
@benwilson512 Thanks for your rapid reply, I would have to do that for the whole application, the Repo is used in multiple modules. I was looking more for a global setting or so. I just upgraded the application and facing this problem, I was expecting to perform better out of the box. But I will keep that suggestion to use it in the case I cannot find anything at a global level. Thank you
benwilson512
@agacode Usually if you wanted to do that “app wide” you’d basically just do it at the controller or plug
callfunction or whatever. Doing it app wide is a tricky concept with all the different processes running around. Most processes never even touch the database, so there has to be an explicit point at which you say “This process is checking out a database connection”.agacode
@benwilson512 I’ll try that and see how it goes. What pool? regular ConnectionPool or Ownership or any other?
benwilson512
Regular. If your responses are taking 40 seconds though I’d seriously audit the database requests being made. Could you also supply the actual mechanism you’re using to benchmark?
agacode
There is almost no time for refactors due to a constant business need for new features and other constraints that don’t allow the developers directly access/audit the DB.
But my comparison/baseline is the following:
old version 6s vs new version 40s (Same old code, project generated from scratch and adjusted)
We had benchee before for the old version although we haven’t run it in a very long time.
benwilson512
By benchmark I mean what are you using to generate the 2000 req / sec?
In rereading your original question, I’m curious how you’re measuring this data. If after the upgrade everything completed nearly twice as fast it seems impossible that the average request time increased by nearly a factor of 7.
agacode
Oh sorry I misunderstood your question, we use JMeter to do the load tests, we also have production API clients that send a big batch of requests and provide us later with the amount of requests they sent, also HAProxy is registering all the connections/requests.
Each request individually takes longer (I assume because of the amount of queries we execute within the request and it is multiplexing too much), the whole batch takes a bit less than before. Maybe there is no logical explanation for that, but those are the facts.
I will tests with Repo.checkout in a request level place and see how it goes. Thank you so much!
benwilson512
I would consider renaming the question to be more about the general performance issue you’re experiencing after upgrading by the way. Doing an explicit database checkout may help, it might also not. The issue you’re experiencing is the slowdown, there may be other avenues to approach in so far as improving that goes.
agacode
Done
…