如果您对OTP层次结构的设计不正确，您会在生产中看到哪种错误？
说有一个瓶颈，就是您的工作人员和代码块不足，基本上是超时错误吗？
有没有办法监视您是否有瓶颈？
我知道您可以编写基准测试，请确定我可以为此类测试提供一个很好的基准测试示例吗？
答案 0 :(得分：1)
除了不正确的监督树设计之外，另一个常见的错误是向一个进程发送太多消息。该进程将成为瓶颈，因为它们在进程邮箱中有太多邮件。在erlang VM中，向大型邮箱发送消息的成本甚至更高。使用默认的进程优先级设置，它将阻止调用方进程（就像您尝试使用GenServer.call一样），因此这些进程将很快成为系统中的瓶颈。在这种情况下最有可能发生超时。
虽然您可以使用Process.info(pid, :message_queue_len)来检查消息队列大小，但是还有一个类似recon的库可以帮助您在运行时监视信息流程，VM。在开发中，我要做的就是简单地在iex中运行:observer.start。 Erlang Observer提供了一种非常直观的方法来检查系统信息，主管树和过程信息。
答案 1 :(得分：0)
说有一个瓶颈，就是您没有足够的工作人员和代码块，这基本上是超时错误吗？
除非明确说明实际情况，否则无法抵御“工人不足”问题。每小时只有1M的工人处理1条消息，效率极低；每秒有1个工人处理1M条消息，这是很困难的。没有银弹。 旁注：对于此类特殊问题，我们使用GenStage处理背压。
最常见的问题AFAICT是监管树的设计不当，其中一名工人的崩溃导致状态不一致（其他工人对此名称或类似名称作了过时的引用）。保持远程连接以说 RabbitMQ 。当后者崩溃时，应该重新启动/重新配置所有依赖项。
这类问题很容易测试。一个人编写了一堆测试，使每个人都在监督树中崩溃，并确保崩溃的一个人复活后一切正常。
ErlangVM 经过明确地针对高负载进行了优化，可以立即处理一些常见的问题，当遇到非常不常见的情况时，除了了解瓶颈所在之外，没有收据（总是坐在您永远不会想到的地方:)并修复这个特定问题。
我怀疑是否会存在任何通用解决方案。