victorolinasc
Hi everybody!
I have an expensive CPU action that I want to serve through a public internet endpoint. It doesn’t matter what it does, just that it usually takes some time (seconds) and that it costs CPU (say a few percent of CPU usage). For a real use-case you can think of an expensive hashing algorithm like PBKDF or any other on a signin endpoint.
What I want to avoid is being hit by a flood of requests and suffer from resource starvation where everything would become unresponsive. Like the signin case, a public endpoint without authentication makes it a perfect target for attacks that want to bring the server down. Think that all network solutions are in place like rate-limiting, WAFs and so on.
I thought about 2 strategies in the BEAM:
1- Using a pool of processes. I’ve implemented this with poolboy and works fine but is hard to tune it. I have to benchmark the cost of the function in a production server and reach a pool size that will be a good enough “sharing” of resources. I am thinking about switching to wpool and having a bigger than needed pool with a callback module that would check CPU usage before dispatching to the pool. This seems to me very unreliable and prone to error… If we get several concurrent requests and the CPU usage from all of these is under control, then they would all start at the same time and the CPU would spike anyway…
2 - Using a slave node for doing just this operation and fight with the emulator flags to have it use other logical cores. Suppose I have 8 cpus available, I could dedicate 2 or 3 to the slave node and the rest to the main system. Though, with this strategy, it would still be vulnerable to resource starvation and make all calls to it fail which is not my intention here. I’d rather have timeouts than a denial of service.
So, I’d like to know if there are any other algorithms or strategies to deal with this. I appreciate your time 
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
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
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
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 19 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
victorolinasc
Awesome! Thanks a lot for the info! Will try to play with uwieger/jobs
A very interesting library to have under my set of tools.
Thank you all for your replies. We have tested the process pool approach and it is handling it pretty good up to now. Though the subject keeps interesting me and I will try other approaches.
cmkarlsson
I have used
jobs(GitHub - uwiger/jobs: Job scheduler for load regulation · GitHub) for these kind of things before. It allows you to have a queue which is regulated based on CPU sampling for example.Or you can use a “circuit breaker” library to deal with this. They generally implement the correct algorithms for this. I’ve used
fuse(GitHub - jlouis/fuse: A Circuit Breaker for Erlang · GitHub) in the past but it hasn’t had any updates the last couple of years so don’t know if it will work with the latest erlang versions.dimitarvp
You could also try hCaptcha as a fallback.
victorolinasc
Thanks! That is also a nice idea. Our “challenge” was an external service that went down (Google
).
We are testing other on-premises fallbacks . There are some interesting alternatives currently…
Thanks for your suggestion!
drakkhenn
I think I would have first used a “simple challenge” just to avoid “script kiddies” then your “annoying algo”. If you have a lot of users, to a specific cpu → server → hardware (GPU).
victorolinasc
Thanks! That is my current approach and it works quite well with the only caveat of having to “guess” the proper pool size for each environment.
The “normal” schedulers context switch very frequently but dirty_cpu schedulers might not do that (depending on the NIF implementation) so I am trying to be safe here and not ever allowing it to reach 100%.
dom
In that case I think you could just use a big enough pool (say 2 * core count) for low priority requests, and do the work directly in the request handler for high priority requests, bypassing the pool.
Reject low priority requests if the pool is full. You can also use s_broker if you want to get fancy and allow some queuing to deal with sudden spikes.
Even if the pool is saturated and CPU usage reaches 100%, the app will stay responsive, since the BEAM context switches very frequently.
chasers
Ah … yeah I had an API product for years that was designed to be async. So people would POST jobs with a callback URL. We’d hit that with results, or with an endpoint to gather results when the job was finished. It worked well and people understood why we had to do that based on the type of work we were doing.
Other than that, I would limit concurrency with a pool. So the whole system can have N number of concurrent jobs. You don’t even need poolboy for this … just a Dynamic Supervisor limiting the number of children.
I personally wouldn’t try and base it off of CPU. I’m sure it can be done I guess but I’d start with concurrency limiting I think to play with that. Maybe then have a failsafe based on CPU if you want to push the boundaries a bit more.
victorolinasc
Unfortunately our solution here is not LiveView based but HTTP API based =/
chasers
You can easily do this with LiveView.