Heroku 平台扩展指南

Question

我正在免费的Dyno上运行一个基于 NodeJS 的应用程序，连接到 mongohq-MongoDB 。我想将其迁移到使用业余爱好Dyno，这样做的动机不仅是避免睡眠时间，而且是为了实现更高的 HTTP 流量吞吐量。

阅读Scaling文档和Procfile文章让我对如何在 Heroku 上进行扩展感到困惑。

在Procfile文章中，据说Web进程类型是唯一将从 Heroku 路由网格接收 HTTP 流量的进程。

所以我的问题是：

1. 当已经有一个爱好Dyno 正在运行时，执行“heroku ps:scale web+2”将导致同一 Dyno 上有 +2 个 Web 进程，或者添加两个爱好Dyno（总共三个爱好Dyno）？
   • 总共三个爱好Dynos 意味着 3 个 Web 进程和 27 个非 Web 进程可用？
2. 在这个答案中，建议使用cluster模块来分叉线程来处理 HTTP 请求，如何确定应该创建的工作线程数（在循环中// fork worker processes）？
3. 我应该如何决定何时水平扩展我的应用程序（添加更多相同类型的 Dyno）或垂直扩展（更强的 Dyno，如标准 1X/2X）
   • 应该触发水平缩放来处理更多的请求？
   • 应触发垂直缩放以处理较繁重的处理（需要更多计算资源来响应相应的请求？）

注意，

在这个答案的“缩放”部分中，Dynos 的结果对于上面的问题 #1 仍然不清楚。

---

请考虑到应用程序优化（例如查找/删除瓶颈等）超出了这个问题的范围，因为它的目标是更好地理解 Heroku 平台上的资源利用。

Answer 1

我会把这些按顺序...

1. 不，您的爱好层中有 10 个进程类型，这意味着如果您有 1 个 Web dyno，您可以为同一应用程序运行另外 9 个 dyno，这另外 9 个可以是您的 Procfile 中的任何条目。

   您只能有一个 Web dyno，其余的是 Procfile 中的其他（最多 9 个）条目。

2. 这主要取决于内存，这取决于您在应用程序中执行的操作，如果它相当小，那么您可以运行更多，Node.js 集群工作线程是单独的 Node.js 进程，碰巧共享相同的套接字，并且操作系统跨进程分发请求。

3. 您需要在这里考虑请求的响应时间，如果您看到“缓慢”的请求，您要么进行优化，要么当您确定已优化时，您需要扩大规模，这可能会或可能不会涉及增加数量运行 dynos 时，可能是您的应用程序与之通信的对象减慢了请求（例如数据库或外部服务）。

什么定义了“慢”请求？

嗯...您可能会考虑响应时间的“预算”，但是您需要测量请求/响应时间，通常是相当高的粒度，这样您就可以隔离导致响应缓慢的原因，并确保您可以扩展正确的部分，如果是一个优化不佳的数据库查询导致您悲伤，那么将您的dyno计数增加一倍不会有任何效果，如果有什么可能会让事情变得更糟，所以您需要测量总体响应时间和魔术请求。

水平缩放和垂直缩放有很大不同，这个问题的答案取决于您的应用程序，更大的测功机有更多的内存，这意味着它们可能可以在内存中缓存数据，或者处理来自外部服务的更大的有效负载，还有 Performance-M 和 Performance -I 测功机“专用”于客户，因此，您将受益于更可预测的负载曲线。

如果您有多个网络测功机，那么 Heroku 路由器将在它们之间随机分配传入请求，这意味着它们在一段时间内将收到大约相同数量的请求，并且“Little's Law”适用于此，这里有一个很好的解释如何将其应用于此处的 Web 请求，如果您想要的并发请求在当前平均响应时间不起作用，您有两个选择，减少平均响应时间，或增加容量。

此外，Hobby 层不会使您的测功机更快，它允许您拥有更多进程（测功机）并且它们可以每天 24 小时运行，但您需要使用较大的测功机类型之一来获得性能提升。