4 ms·

> when you rent dynos, you actually rent processes True; more dynos, more processing capacity. I was replying to the suggestion that dynos are processes, but t

> when you rent dynos, you actually rent processes True; more dynos, more processing capacity. I was replying to the suggestion that dynos are processes, but they aren't. Agreed, in common discussions this distinction doesn't matter much, and you correctly mentioned that it is possible to run multiple processes in one dyno. > using (and paying for) a heroku dyno is basically the same as using a process on a dedicated server Partly true. Using an Heroku dyno is basically the same as getting a small (although 2X dynos have 1 GB memory allocated) temporary virtual server in which a limited number of processes run, often just one. No running process equals to no dyno, I think. Paying for an Heroku dyno is basically the same as renting (and releasing) a small virtual server for the duration of a running process (and for possibly very short periods of time). That is especially true for one-off dynos: a dyno only for the duration of one command, but those are charged just like web or worker dynos. Normally, we aren't paying for processes on (dedicated or virtual) servers, but are buying the server capacity whatever we do with it (limited by the server resource allocation). So that is indeed one of the differences between Heroku's PaaS solution and other IaaS offerings (and we both agree on): paying for the (running) processes instead of paying for the capacity made available for you.

jt2190 13y ago
> ... getting a small... temporary virtual server in which > a limited number of processes run, often just one. Is it "often just one" process running because of some limit enforced by Heroku, or is it simply because, well, many people don't bother to spawn additional processes? Do additional processes "wait" for other processes to finish before proceeding? (I'm about to run another experiment on Heroku...)
- jschulenklopper 13y ago
  Heroku enforces a 512 MB memory limit (or 1024 MB on the 2X dynos), so that limits the practical number of processes running in the same dyno... especially if those are (heavy) full-stack web applications. Additionally, processes share the same CPU, so you'll not get the same performance as two processes in their own dynos. See https://devcenter.heroku.com/articles/process-model https://devcenter.heroku.com/articles/process-model and https://devcenter.heroku.com/articles/rails-unicorn https://devcenter.heroku.com/articles/rails-unicorn. Unicorn forks multiple OS processes within each dyno to allow a Rails app to support multiple concurrent requests. Generally no more than 3-4 processes will fit in one dyno.
oelmekki 13y ago
> Paying for an Heroku dyno is basically the same as renting (and releasing) a small virtual server for the duration of a running process (and for possibly very short periods of time) > Normally, we aren't paying for processes on (dedicated or virtual) servers, but are buying the server capacity whatever we do with it (limited by the server resource allocation). That's one of the thing that makes me say we pay for processes, on heroku (even if it's indeed oversimplified). A dedicated or virtual server is not only about process and memory. You can have access to sendmail on it, handle uploads, store long and exhaustive logs, perform specific task via third party application (like resizing images), ssh to machine if any problem need deep inspection, etc. The heroku model is about extremely specialized services. Whatever you need that is not processor share or memory needs an external addon. I'm ok with that, but it has to be stated clearly. It's not at all like if you had a standard virtual server. Your stance "Paying for an Heroku dyno is basically the same as renting (and releasing) a small virtual server for the duration of a running process" would perfectly do. Way better than heroku's one "Dynos are isolated, virtualized Unix containers, that provide the environment required to run an application" which could let think that it's a regular virtual server. Well, sendmail, for me, belongs to an "environment required to run an application".

jt2190 13y ago

> ... getting a small... temporary virtual server in which > a limited number of processes run, often just one. Is it "often just one" process running because of some limit enforced by Heroku, or is it simply because, well, many people don't bother to spawn additional processes? Do additional processes "wait" for other processes to finish before proceeding? (I'm about to run another experiment on Heroku...)

jschulenklopper 13y ago
Heroku enforces a 512 MB memory limit (or 1024 MB on the 2X dynos), so that limits the practical number of processes running in the same dyno... especially if those are (heavy) full-stack web applications. Additionally, processes share the same CPU, so you'll not get the same performance as two processes in their own dynos. See https://devcenter.heroku.com/articles/process-model https://devcenter.heroku.com/articles/process-model and https://devcenter.heroku.com/articles/rails-unicorn https://devcenter.heroku.com/articles/rails-unicorn. Unicorn forks multiple OS processes within each dyno to allow a Rails app to support multiple concurrent requests. Generally no more than 3-4 processes will fit in one dyno.

oelmekki 13y ago

> Paying for an Heroku dyno is basically the same as renting (and releasing) a small virtual server for the duration of a running process (and for possibly very short periods of time) > Normally, we aren't paying for processes on (dedicated or virtual) servers, but are buying the server capacity whatever we do with it (limited by the server resource allocation). That's one of the thing that makes me say we pay for processes, on heroku (even if it's indeed oversimplified). A dedicated or virtual server is not only about process and memory. You can have access to sendmail on it, handle uploads, store long and exhaustive logs, perform specific task via third party application (like resizing images), ssh to machine if any problem need deep inspection, etc. The heroku model is about extremely specialized services. Whatever you need that is not processor share or memory needs an external addon. I'm ok with that, but it has to be stated clearly. It's not at all like if you had a standard virtual server. Your stance "Paying for an Heroku dyno is basically the same as renting (and releasing) a small virtual server for the duration of a running process" would perfectly do. Way better than heroku's one "Dynos are isolated, virtualized Unix containers, that provide the environment required to run an application" which could let think that it's a regular virtual server. Well, sendmail, for me, belongs to an "environment required to run an application".