Yep, we are using Erlang 22 with Elixir 1.9.0 (we also tried 1.9.1)

In development we are using:

elixir 1.9.0-otp-22
erlang 22.0.5

and in production we build using official elixir image.

However, the compilation times are the expected ones (more or less, it takes time but it’s due to cross dependencies between modules), the issue is when we start the release itself, that produces a CPU spike and a quite long time until the first request is served, which doesn’t happen with Distillery.

Ok, so I’ve created a bunch of test cases and measured the time to entry in Application.start:

## Distillery (elixir 1.8.2-otp-21)
- date && _build/prod/rel/app/bin/app foreground: < 3 seconds
- date && _build/prod/rel/app/bin/app console: < 3 seconds

## Distillery (elixir 1.9.1-otp-21)
- date && _build/prod/rel/app/bin/app foreground: < 3 seconds
- date && _build/prod/rel/app/bin/app console: < 3 seconds

## Elixir releases (elixir 1.9.1-otp-21)
- date && _build/prod/rel/app/bin/app start: 10 seconds
- date && _build/prod/rel/app/bin/app start_iex: 10 seconds

## env MIX_ENV=prod mix phx.server --preload-modules (elixir 1.9.1-otp-21)
- date && env MIX_ENV=prod mix phx.server --preload-modules: < 3 seconds

## Experiment: Elixir releases without runtime configuration (elixir 1.9.1-otp-21)
- date && _build/prod/rel/app/bin/app start: < 3 seconds

As you can see, the Elixir releases with runtime configuration are way slower than distillery (which has the same runtime configuration). By accident I tried releases without runtime configuration and noticed this was much faster (in the same range as distellery - my feeling says it’s still a bit slower, but hard to measure/benchmark correctly so don’t trust me on this)
(Just as confirmation, my runtime configuration does nothing special, only reading environment variables and parsing a 4 values to Integer. It’s the same configuration that I use in distillery as well)

I’ve also tried: env MIX_ENV=prod mix phx.server --preload-modules which should preload and the startup speed is in the same ballpark as distillery, releases without runtime configuration.

So my conclusion is that there is something wrong with elixir releases with runtime configuration.
Maybe that’s easier to confirm for someone else?

This happens to me also, it’s a private project with a high number of modules, and cannot publish it open source.

However I see the same issue you are having, but in a different scale (because of the number of modules, which is totally understandable).

As @jola said, it is expected that Releases take longer than mix phx.server, the real issue is that mix releases are taking 3x time the start time of a distillery release in some scenarios (we have 4 elixir projects in prod, and only this one is suffering this issue).

In our particular case, we tried removing some aspects like external libraries (AppSignal for example) in case it was causing some trouble starting the agent… but no luck. We end up rolling back to distillery until this gets solved or we have more time to investigate more to fill a proper issue in the core.

if someone thinks about anything we can look at, I will be pleased to try things.

Releases should start slower than mix phx.server because they preload modules. Mix will load modules lazily, so it starts instantly but you get a slower application until all modules have been loaded instead. Because releases preload modules they start slower but are then “warm”. Releases also start twice, once to load runtime configuration and the second time for real.

It’s hard to know in your case if mix releases are slower than distillery, unless you have a comparison?

Best thing would be to set up a repo that reproduces it. The core team would probably be happy to look at it.

I hope you find an answer