So to be able to get shared-cpu-8x I would need have a machine with a shared CPU type and 8 cpus?
fly machine update --vm-cpu-kind shared --vm-cpus 8
I always assumed the number of cpus meant actual shared cores, not fractions of a cpu.
you can use fly machine update --vm-size shared-cpu-8x.
before this update, that was what it meant (and we allocated one real core to at most 16 Machines). as mentioned in the previous thread, unfortunately due to noisy neighbours people were getting worse performance than expected 
1 Like
Thanks for the clarification.
Honestly I’d prefer to use a single performance CPU if I wasn’t forced into using 2GB of memory.
BTW is there a way to update all the machines in an app in a single command?
It’s incredibly tedious to update machines one by one.
it would be nice to have performance CPUs with less memory (I have some performance-2x using 500mb…) but unfortunately I don’t think that’s planned at the moment.
I generally do for m in $(fly m list -qa my-app-name); do fly m update $m --whatever-flags to update all machines; it still takes a long time but I can just leave it to do its thing.
1 Like
Has there been any follow-up from Fly about the lack of communication around this change? Policy updates or assurances that breaking changes like this would not roll out without advance notice delivered to affected users?
Last year I started tinkering with an app, targeting and testing on Fly for at least an initial release. Although the main workload may not ultimately be that well-suited to it, it still works in my testing. But I’m very wary of trying a full launch if Fly’s approach to breaking changes is still “f*** it, ship it!” without communication. I don’t want users frustrated with me not because of a technical fault with me or Fly, but because Fly just disregarded any responsibility to its users.
I like the platform here. I built a couple things on it, and I really want to use it. But things like this give me serious pause.
1 Like
I had to increase the machines in an app to shared-cpu-8x:2048MB to get a similar performance as I used to get with shared-cpu-2x:512MB . Probably the same performance as a single shared cpu as ffmpeg is single threaded for audio encoding. I used 2 cores in case an extra audio encoding job was needed which was almost never used.
So now I’m paying 4x more for the same result without the extra backup core. Plus I have to get 1.5GB of extra memory I don’t need, per machine.
This isn’t working for me.
I don’t disagree with any of the frustration in the thread, but with my practical hat on, it sounds like folks have had to bump up to over-provisioned machines. This, in other words, could cause an overspend, assuming each job currently gets one throwaway machine.
I wonder if anyone here would be able to solve this issue as follows: when a new job is queued, an existing machine is found that is only running one job, and the machine is given the additional job, which it processes in parallel. That machine would then exit at the completion of both jobs, rather than just handling one. Just a thought.
This isn’t possible anymore with shared CPUs as you are getting fractions of a CPU, not shared cores. So shared-cpu-8x means you get half of a single CPU core, not 8 shared cores as it used to be.
Yes, if your work is CPU bound, I see what you mean. Perhaps my idea would work for folks whose jobs are memory-bound.
In your case, could you hand off your job to AWS lambda or similar? Lambdas can now run from a Docker image, so there may not be much work to do. I appreciate it’s a pain to be split over two cloud operators, but it’s probably less hassle than moving everything out of Fly, and less onerous than waiting for Fly to create more flexible compute offerings.
Of course I can solve my problem in any number of ways but that’s not really the point of this discussion.
I just veered it in a new direction, I guess. Someone may find it helpful; it may be an antidote to negativity, as I find some of these carping threads to be counterproductive. Building software, especially solo, sometimes needs unreasonable amounts of optimism, viz: “what do I need to get this clucking thing to work!?” 