Guidelines for Scaling on Heroku Platform
我在免费的Dyno上运行一个基于NodeJS的应用程序，连接到mongohq-MongoDB。我想迁移它以使用业余爱好Dyno，这样做的动机不仅是避免睡眠时间，而且还能实现更高的HTTP流量吞吐量。
阅读Scaling文档和Procfile文章让我对如何在Heroku上进行扩展感到困惑。
在Procfile文章中，据说Web进程类型是唯一将从Heroku routing-mesh接收HTTP流量的进程。
所以我的问题是：
- 共有三个爱好Dynos意味着3个网络流程和27个非网络流程可用？
- 应该触发水平刻度来处理更高的请求数量？
- 应该触发垂直比例以处理更重的处理(需要更多的计算资源来提供对相应请求的响应？)
N.B，
在这个答案的Scaling部分，结果Dynos在上面的问题＃1中仍然不清楚。
请考虑到应用程序优化(例如查找/删除瓶颈等)超出了本问题的范围，因为它的目标是更好地理解Heroku平台上的资源利用率。
我会按顺序拿这些......
不，您在Hobby层中有10种流程类型，这意味着您
拥有1个网络dyno，你可以再运行9个dynos
相同的应用程序，这9个可以是您的Procfile中的任何条目。
您只能有一个web dyno，其余的是Procfile中的其他(最多9个)条目。
这主要取决于记忆，这取决于你在做什么
你的应用程序，如果它相当小，那么你可以运行更多，
Node.js集群工作者是独立的Node.js进程
共享相同的套接字，操作系统分配请求
流程。
如果你有的话，你需要考虑这里的请求响应时间
看到"慢"请求，您要么优化，要么在您确定时
你已经优化了，你需要扩大规模，这可能涉及也可能不涉及
增加跑步动力的数量，这可能是你的事情
应用程序谈话正在减慢请求(例如数据库或外部
服务)。
什么定义了"慢"请求？
嗯......您可能会考虑响应时间的"预算"，但是您需要测量请求/响应时间，通常是相当高的粒度级别，这样您就可以隔离导致响应缓慢的原因，并确保您可以扩展正确的部分，加倍你的dyno计数将无法实现任何目标，如果它是一个优化不佳的数据库查询导致你的悲伤，如果它可能会使事情变得更糟，所以你需要测量整体响应时间和魔术请求。
水平缩放和垂直缩放是完全不同的，答案取决于您的应用程序，较大的dynos有更多的内存，这意味着它们可能可以缓存内存中的数据，或处理来自外部服务的更大有效负载，还有Performance-M和Performance -I dynos"专注于"客户，因此，您将受益于更可预测的负载配置文件。
如果你有多个web dynos，那么Heroku路由器将随机分配传入请求，这意味着他们将在一段时间内收到大约相同数量的请求，并且"Little's Law"适用于此处，有一个很好的解释如何将此应用于此处的Web请求，如果您所需的并发请求在当前平均响应时间不起作用，则您有两种选择，缩短平均响应时间或增加容量。
此外，Hobby等级不会让您的dynos更快，它允许您拥有更多进程(dynos)并且它们可以每天24小时运行，但您需要转到其中一个较大的dyno类型以获得性能提升。