I have a somewhat CPU intensive service I want to deploy on Fly (since Google Cloud Run crapped out on me).
I could probably run it with 256MB of RAM but from the pricing page it seems I’d need to get the dedicated-cpu-1x plan which has 2GB of RAM and costs $31/month.
Hi @pier
Have you tried out the shared-cpu-1x option? Also, I believe that there is also shared-cpu-2x up to shared-cpu-8x that you could try. The pricing page hasn’t yet been updated but essentially just multiply the shared-cpu-1x price by the number of CPUs (e.g. shared-cpu-4x is ~$7.76).
Thanks @charsleysa I hadn’t considered using multiple shared cores. That could work for my use case.
Although, if I could have multiple dedicated CPU cores with low RAM that would be amazing.
Just an extra note that shared-cpu-2x to shared-cpu-8x is currently only available with the new machines feature.
Will those configs also be available for regular apps at some point?
I do plan on getting into machines when I have a bit of time, but not right now.
We are not going to backport the multiple shared cores feature to regular apps. This is a limitation of Nomad for us.
The transition to machines should be done in a few months and there won’t be any distinction between an app using machines and an app using Nomad.
Thanks @jerome .
So, if I understand this correctly, I’ll be able to create/manage a machine app using the CLI just like I’m creating a regular app today?
Yes, I think the plan is to make it work just like fly deploy does, but with machines. it should be transparent and work the same as before.
I don’t yet know how we’ll let people manually manage machines and use current deploy-like behaviour though 
That sounds great!
Very exciting times for Fly users
Is it possible you’re capping CPUs to prevent abuse like Bitcoin mining?
I’m testing encoding a small 3 mins .wav file with a single shared CPU and… I cancelled it after like 50 mins.
So I then upscaled the app to use 1 dedicated CPU and 2GB of RAM and I’m still waiting after 1 hour.
The same audio file takes about 45 seconds in my 2017 Core i5. I’m using ffmpeg spawning a new process. The Lame MP3 encoder is single threaded so the number of cores doesn’t matter here.
As a side note, even with 2GB of RAM available, the app never consumed more than 200MB which is why for this type of workload RAM doesn’t matter much.
Hmm, no we don’t throttle like that! We just use CFS (fair scheduling).
Can you give us example code to reproduce the issue?
I can take a look tomorrow.
Thanks @jerome I will create a repro app so you can test it.
Here it is @jerome .
Basically the app prints a start time, encodes an MP3 using ffmpeg, and when finishing prints the end time. There’s a very small test.wav file.
You should be able to just change the Fly app name in the fly.toml and deploy.
In my local machine the app takes 0.36 seconds to encode and prints this:
start time 2022-06-29T02:30:04.464Z
end time 2022-06-29T02:30:04.827Z
total time 0.363 seconds
I deployed it on a shared-cpu-1x on Fly. It’s been working for like 10 minutes and it still hasn’t finished encoding the .wav.
2022-06-29T02:36:27Z app[ac526e16] ams [info]start time 2022-06-29T02:36:27.677Z
Edit:
Not sure what’s going on, but the Fly app never finished encoding the audio.
I tested it on a Vultr VPS running Ubuntu and a shared CPU and it was even faster than my iMac:
start time 2022-06-29T03:28:15.307Z
end time 2022-06-29T03:28:15.486Z
total time 0.179 seconds
Attempting to run this this morning.
Locally (Apple M1 Max), it took 3s once. Then, it hung forever on the next tries.
Are you pushing your test.mp3 as part of the build? Add test.mp3 to a .dockerignore. Looks like the program hangs if test.mp3 exists. You can also add the -y flag to ffmpeg to overwrite the existing file.
As far as I can tell, that’s probably the issue!
(I haven’t been able to deploy it to Fly because of the bug with running recent ubuntu images on some of our older kernels, working on moving my builder somewhere else so I can test this on Fly)
Sorry. It was late at night and forgot to create the .dockerignore file. I’ve pushed it to the repo now.
I’m trying to deploy it to a new app but it fails with the Failed due to unhealthy allocations error. Is this because of the bug you mention? Would I be able to deploy with Alpine? I used Ubuntu for the repro because I need it to install other packages in my production app which are not available for Alpine.
Also 3 seconds on the M1 Max? Woah that’s slow. I imagine it’s because it’s running inside Docker with Rosetta.
That should work yes. I tried with an older Ubuntu and got:
/usr/src/app/index.js:1
import { spawn } from 'child_process';
^
SyntaxError: Unexpected token {
Running directly on my mac! Future runs were 0.1s, not sure why the first one was slow.
I just ran it with alpine on a machine:
start time 2022-06-29T16:07:09.190Z
end time 2022-06-29T16:07:09.434Z
total time 0.244 seconds
Dockerfile:
FROM node:18-alpine3.15
USER root
RUN apk add -u ffmpeg
WORKDIR /usr/src/app
COPY package.json .
COPY package-lock.json .
COPY . .
ENV NODE_ENV production
ENV PORT 8080
ENV HOST 0.0.0.0
CMD ["node", "index.js"]
Edit: Once warmed up a bit (after a few invocations)
/usr/src/app # node index.js
start time 2022-06-29T16:14:56.359Z
end time 2022-06-29T16:14:56.496Z
total time 0.137 seconds
That could be if you’re running an old version of Node.
I will try deploying with Alpine and see what happens.
So I’ve added Fastify to be able to respond to HTTP and encode the file at /encode. Check the repo.
I deployed it to Fly with Alpine on a shared-cpu-1x and it’s running fantastic. This is the response:
{
"startTime":"2022-06-29T16:41:30.169Z",
"endTime":"2022-06-29T16:41:30.306Z",
"totalTimeSeconds":0.137
}
It’s true on this repro I made the mistake of not adding -y to the command, but on my production app this doesn’t happen. You can see from the CPU graph I pasted earlier that the app was doing hard work.
Is this because I’m using the latest version of Ubuntu? What version do you recommend to use?
I’m not entirely sure why the Ubuntu version would matter, except that it might ship a different version of ffmpeg.
We don’t generally recommend alpine, but if you don’t need to do DNS lookups or ipv6 too much, it might be ok!
If you can reproduce the issue with ubuntu again and get it spinning, you could ssh in there and run strace or perf (but that could be painful to setup) on the process to see what it’s doing.