doogs
I have an elixir/Phoenix app which I am currently load/stress testing before releasing into the wild.
Currently using Tsung as my test tool.
When running test on my local machine (distillery release in PROD mode) the transaction times seem to increase with every user login.
I have run similar tests on the production environment and it seems to follow the same pattern.
See graph below.
tr_deposit is a POST request. this is fine and always under 1 second.
I’ts the logins and page requests that worry me. Is this normal?
even when i change the comeonin bcrypt_log_rounds to 4 it follows a similar curve, although slightly faster.
Note: This is on a phoenix browser pipeline but with CSRF disabled. With CSRF Tsung does not seem to be able to accurately post and I end up getting lots of 403’s.
How is this explained?
What would be a realistic expectation of transactions times when you have 10 users a second logging in?
I thought that these sort of numbers would be easy to manage in Phoenix?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
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
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
idi527
Can you provide what the function that you are benchmarking actually does and your tsung config?
OvermindDL1
For note, Comeonin is specifically designed to be slow to hash the password, that is part of its security, so it will limit the number of simultaneous logins. The general idea is that logging in is fairly rare and using the site once logged in is common. Otherwise I would delegate to an OIDC server for login or so instead.
Thus logging in ‘should’ be slow, it’s to prevent people rapidly checking passwords (even if your database gets leaked!). Page likely shouldn’t be slow but without seeing what it does then can’t say.
But overall, if you don’t want the cryptographic CPU cost of a bcrypt or argon security style then I’d really say handle logging in via another OIDC server or so.