[Dynos] [Large/more-flexible Dyno Sizes]: Dynos with more memory and more and faster CPUs

[bradleybuda]

Required Terms

• [X] I agree to follow this project's Code of Conduct
• [X] I have read and accept the Salesforce Program Agreement

What service(s) is this request for?

dynos

Tell us about what you're trying to solve. What challenges are you facing?

Many of our Heroku workloads are embarrassingly parallel, and we use a traditional job queue approach (Resque) to fan out jobs to workers. However, some of our jobs would benefit from more cores on a single dyno (to take advantage of intra-job parallelism via processes or threads) as well as higher memory limits. The performance-l, private-l, and shield-l dyno types (the largest available on Heroku) are quite small by current public cloud standards, especially the 14GB memory limit.

Because of this limitation, we've moved a small subset of our workloads outside of Heroku, using either AWS's m6i.8xlarge instance type (32 cores, 128 GB memory) or the GCP equivalent. I'd love to move this work back inside of Heroku!

[afawcett]

Thanks @bradleybuda for sharing this. We are looking into this.

[xqliu]

Jump from 1GB shared to 2.5GB dedicate directly without options like 1.5G, 2G makes deployment of JVM based application not convenient and suitable at all, User have to either to use 1GB shared one, which is not enough, or jump to use the 2.5G dedicate plan, which is too expensive.

Wish you can consider to add more planes which is suitable for JVM based application, 2GB would be a sweet spot for JVM scenario.

Thanks.

[ArturT]

It would be great if we could select RAM and CPU sizes in the Heroku dashboard independently. This way, each user could adjust the dyno type to their application needs.

[ro-savage]

Agreed -- we run everything on Performance-L because Performance-M is too small but L is much larger than we need for most of our stuff. Going from 2.5gb to 14gb, and 12x compute to 50x is a massive jump.

At the same time, we have one dyno that would benefit from a significant speed and memory increase.

Providing much closer to the actual options available on AWS would improve Heroku's offering significantly.

[friism]

Thanks for that nuance - I've updated the issue title to also reflect the need for more flexible sizes (eg. in between medium and large). More dyno types is something we're looking to prioritize for sure. Also see this issue: https://github.com/heroku/roadmap/issues/130

[ASayre]

Cross referencing this to #202 as well

[capeterson]

Wanted to share a quick update that we have three new dyno sizes almost ready to go - keep an eye out for a Heroku blog post announcing them officially in the next few weeks.

We've already started using them internally for some of our memory intensive Heroku Connect workloads with some very positive results.

[elimchaysengSF]

We're excited to announce that additional larger dyno sizes are now in General availability! See the blog post or the dev center for more details!

[ArturT]

Thanks for that nuance - I've updated the issue title to also reflect the need for more flexible sizes (eg. in between medium and large). More dyno types is something we're looking to prioritize for sure.

@friism @elimchaysengSF Are you going to add options between M and L dyno? I'm sad you did not introduce it. :( There were upvotes for it.

To give you a practical example. We use Sidekiq in the Ruby on Rails project. It is recommended by Heroku to run 1 process per dyno so we run one Sidekiq process. It consumes 6GB of RAM. We must use PL dyno with 14GB RAM because the M dyno with 2.5GB RAM is too small.

In our case, most RAM is not used. CPU in PL dyno is idle because Sidekiq does not leverage more vCPUs. The only workaround to utilize dyno better would be to break the rule of running one process per dyno. I would prefer to have a dyno type with 6-8GB RAM and less CPU and scale this dynamically using the Judoscale add-on based on the Sidekiq queue size.

[elimchaysengSF]

Hey @ArturT - your thoughts regarding smaller and more granular sizes has been the number one feedback so far in the few days since our GA. Transparently it's something we really wanted to include with this release of new dyno types (obviously supported with the comments/upvotes you called out in this ticket), but we had some technical limitations that prevented us from adding the smaller types. We're working through those blockers and it's something we will be investing in going forward. I've opened up a new ticket to keep the feedback more specific to smaller/flexible types here https://github.com/heroku/roadmap/issues/276#issue-2219366485

[ArturT]

@elimchaysengSF I'm happy to hear it's still on your roadmap. Thank you.