App V2 Machines + Phoenix + Alpine makes random delay

Questions / Help
1

When I access my app via https://feder.is, it takes random seconds for the server to respond. It’s very irregular. Sometimes it’s right up, sometimes it delays until Safari gives up. Once it responds, it usually works fine for a while. Fly.io console says nothing about this problem.

But it doesn’t happen with https://feder-app.fly.dev.

What would be the problem and what tools can I use to analyze it?

This is my dockerfile.

# Start a builder.
FROM elixir:alpine AS builder

# Work in `/app` directory.
WORKDIR /app

# Set environment variable for production.
ENV MIX_ENV="prod"

# Get basic tools.
RUN apk add --no-cache build-base git

# Get package managers.
RUN mix local.hex --force && \
    mix local.rebar --force

# Get dependencies.
COPY mix.exs mix.lock ./
RUN mix deps.get --only $MIX_ENV

# Copy configurations.
RUN mkdir config

COPY config/config.exs config/$MIX_ENV.exs config/

# Compile the dependencies.
RUN mix deps.compile

# Copy the app and digest its assets.
COPY lib lib
COPY priv priv
COPY assets assets
RUN mix assets.deploy

# Compile the app.
RUN mix compile

# Setup runtime.
COPY config/runtime.exs config/
COPY rel rel
RUN mix release

# Start a runner.
FROM alpine:3.16 AS runner

# Work in `/app` directory.
WORKDIR /app

# Set environment variable for production.
ENV MIX_ENV="prod"

# Enable IPv6 network for Fly.io.
ENV ECTO_IPV6 true
ENV ERL_AFLAGS "-proto_dist inet6_tcp"

# Get basic tools.
RUN apk add --no-cache libstdc++ ncurses-libs openssl

# Copy the app.
COPY --from=builder /app/_build/${MIX_ENV}/rel/feder ./

# Start the container.
CMD bin/migrate && bin/server
2

Is running migrate usual for Phoenix? This is being run every time the Machine with that docker-image is started-up by Fly. Profile and optimize the code for fast app process (docker entrypoint process) start-up when using Machines.

How long are you keeping the Machine around after the it is done serving a request?

1 Like
3

I’m confused. I think CMD bin/migrate && bin/server only runs once when I deploy/redeploy them. Fly.io doesn’t stop/start them arbitrarily. Please let me know if I’m wrong.

I don’t understand your question of how long I keep it around. I thought it’s always on like a server, unless I stop them.

I’ve tried CMD bin/server, without migrate. It doesn’t make any difference.

4

I’ve tried online webpage test services. They say they cannot resolve https://feder.is.

When https://feder-app.fly.dev/ works fine.

5

Fly Machine VMs are ephemeral: Advantages/Disadvantages of Machine Apps - #2 by fideloper-fly

They are very much like AWS Lambda functions in one sense.

If you do not have a need for Machine-specific controls over your Fly app, try Fly Apps v1 instead (you’d have to create a new app as conversions from v2 to v1 or vice versa aren’t yet supported).

1 Like
6

That sounds more like a DNS issue to me. I don’t necessarily think this is related to using Machines.

# Returns nothing
dig +noall +answer a feder.is

# Returns an ipv6
dig +noall +answer aaaa feder.is

I suspect that not having an IPv4 associated with the app is the primary issue - some places don’t handle IPv6.

Additionally, dig +noall +answer aaaa feder.is was a bit slow to respond the very first time I tried it - any chance the DNS service being used isn’t that great?

7

That’s what I was thinking. Machine is fine. It must be a DNS issue. Maybe it’s Alpine linux.

I removed A record because UI didn’t really promote them, unlike before. I’ll try allocating a V4.

Does DNS service means the server? My DNS server is ISNIC, where I purchased .is domain. It’s an Icelandic, not very commercial-grade DNS server. Should it matter though? I’ve been using it all the time but never really encountered this problem before.

8

It actually fixed it up.

ips allocate-v4 it is.

Thank you so much!

3 Likes