Erlang（或 Elixir）性能（每秒请求数）比 jruby 慢？答案

【问题标题】：Erlang (or elixir) performance (requests per second) is slow vs jruby?Erlang（或 Elixir）性能（每秒请求数）比 jruby 慢？
【发布时间】：2014-08-14 07:21:03
【问题描述】：

作为一名 ruby 专家，我决定采用 erlang 以获得高性能、可靠的后端。设置非常简单：获取 post 请求，向 redis 写入内容，返回统计信息。所有的json。这也是我如此关心每秒请求数的原因。

选择的工具：webmachine，jiffy 用于 json 编码/解码，poolboy 用于连接池，eredis 用于 redis 通信。

使用的机器：macbook pro，i5 2.4Ghz，8GB 内存。

我的 erlang 每秒大约有 5000 个请求，而 jruby/torqbox 大约有 12,0000 个。 (look here for a complete ruby performance test setup)

我意识到我可以在 erlang 中使用 ets 来节省时间，并将 redis 留作“后台处理”在响应之后编写，但这不会产生什么影响。甚至对 'hello world' erlang 腿后面的简单测试。

有什么建议吗？我做错了吗？

【问题讨论】：

你在使用 jruby 什么？请注意，webmachine不是一个网络服务器。它更接近网络库/框架。如果您仅使用带有 jruby 的 Web 服务器（或直接的机架应用程序），那么您应该考虑直接使用 Cowboy 进行更多的苹果与苹果比较。作为参考，我在旧的 Macbook Pro 上使用 Cowboy 获得大约 11000 req/s。
这里是另一个你可以参考的基准（也许尝试用 jruby 运行它们？）：github.com/mroth/phoenix-showdown
作为比较，您可以查看这些基准测试的结果和源代码：techempower.com/benchmarks
你为什么用 Elixir 标记这个？你使用的是 Elixir 代码还是 Erlang 代码？就人们给出的答案而言，这可能会有所不同。
大家好，非常感谢您的反应如此迅速。 @JoséValim：我意识到 webmachine 在 mochiweb 上运行，但与新的 torqbox 上的红宝石 Grape 相比。所以这是苹果对苹果。为什么要标记长生不老药？ - 这正是因为我尝试了很多解决方案，而凤凰/长生不老药就是其中之一。它的性能略好于所描述的 webmachine 解决方案。感谢您提供有用的链接。会调查。我的印象是 erlang 的效率会击败 JVM。惊讶地发现它没有

标签： performance erlang elixir webmachine requests-per-second

【解决方案1】：

Webmachine - 我不知道。它对我的口味来说很重，我不使用它。
jiffy - 不错的选择。相当快，我经常使用它。
poolboy - 我没听说过，而且我在 Erlang 周围已经好几年了。我肯定会使用cowboy 来表示我期望高性能的任何东西，或者使用yaws 来表示更坚如磐石但仍然表现良好的东西。因为您的基准是牛仔的正确选择，它是最佳性能。
eredis - 我不知道它有多成熟，效率如何。 ets 更适合做基准测试。对于您的 macbook 测试，这并不重要，但对于大型服务器（数十个 CPU），我会检查 ti 是否不是瓶颈和分区表。
最重要的是检查您的虚拟机参数。对于这种负载，至少您应该拥有+K true +A 100。

与我的经验相比，您对 Erlang 的结果似乎太低了。你应该得到几乎十倍大。您的有效负载生成工具也可能存在问题。

最重要的是，这不仅可以被认为是 Erlang 世界的微基准，还可以是 nano 或 atto 基准。当你尝试更困难、更复杂的事情时，真正的力量就会显现出来。并发请求应该以非常复杂的方式相互影响，您必须处理最终一致性并实现它更具可扩展性，并且需要使用异步进程间通信。

【讨论】：

写得真好！请注意：poolboy 用于连接池而不是 Web 服务器。 Riak 和其他几个地方都在使用它，所以我认为它真的很标准。
关于池 - 有没有人有其他有效的方法来处理数据库连接的主题（在我的例子中是 redis）？请详细说明。在此期间，请推荐一个可靠的 redis 或类似的解决方案以实现快速持久性。我很欣赏@hynek-pichi-vychodil 最后一段，并因此想进入 Erlang/Elixir。但是对于我当前的任务，这非常简单，性能是重中之重，如果性能不是更好（我们主要在 ruby/jruby 中工作），我可能很难证明新工具的合理性。

【解决方案2】：

我的 2 美分。你有错误的一端。您正在一种针对 JVM 进行了优化的机器上测试 JVM 针对其进行优化的问题。

你真的不会看到 Erlang/OTP 在 mac book pro 上可用的内核数量方面的优势。这只是我的粗略猜测，但如果看到 Erlang 在少于 8 核的服务器上击败 JVM，我会感到惊讶。在当前硬件上使 JVM 尽可能快地投入了大量的人力/小时。

编写线程安全的 I/O 代码相当简单，真正的问题出现在处理数十到数百个线程之间的内存访问时。

使用 Erlang/Elixir 编写的目标是当前具有 16 或 32 核的高端服务器，并有可能在不久的将来扩展得更高。

【讨论】：

只是您可能想看的东西。 littlelines.com/blog/2014/07/08/… PS：我与基准无关，只是觉得它们很有趣。

【解决方案3】：

仅供参考：“+A 100”对网络没有帮助，它仅用于文件 IO。如果您真的想要快速的网络服务器，请查看 github.com/knutin/elli，它会在硬件上为您提供 80 kprs，而牛仔将为您提供 30 krps。另一方面，许多人指责 elli 没有遵循 OTP 原则。

如果您可以放置一些负载均衡器来清理请求，那么 jiffy 是一个不错的选择，因为 jiffy 会在您的代码中引入段错误 - 请查看问题列表。

无论如何，如果您需要的只是快速 GET -> decode json -> store -> REPLY 工作负载，您可能不想选择 erlang。

【讨论】：