我对优化我的 Ruby on Rails 3.1.3 应用程序的 Unicorn 设置的方法很感兴趣。我目前在 High-CPU Extra Large Instance 上生成 14 个工作进程，因为我的应用程序在负载测试期间似乎受 CPU 限制。在模拟负载测试中，每秒大约有 20 个请求重播请求，我的实例上的所有 8 个内核都达到峰值，并且盒子负载峰值高达 7-8。每个独角兽实例使用大约 56-60% 的 CPU。
我很好奇有什么方法可以优化这个？我希望能够每秒将更多请求集中到这种大小的实例上。内存和所有其他 I/O 一样完全正常。在我的测试过程中，CPU 正在下降。
如果您受 CPU 限制，您希望使用的独角兽进程不超过您拥有的内核数，否则您会超载系统并减慢调度程序。您可以使用 ab 在开发盒上进行测试。您会注意到 2 个独角兽将优于 20 个（数量取决于核心，但这个概念将成立）。
此规则的例外是您的 IO 绑定。在这种情况下，尽可能多地添加内存可以容纳的独角兽。
一个好的性能技巧是将 IO 绑定请求路由到托管许多独角兽的不同应用服务器。例如，如果您有一个使用慢速 sql 查询的请求，或者您正在等待外部请求，例如信用卡交易。如果使用 nginx，为 IO 绑定请求定义一个上游服务器，将这些 url 转发到一个有 40 个独角兽的盒子。CPU 限制或非常快的请求，转发到一个有 8 个独角兽的盒子（你说你有 8 个内核，但在 aws 上你可能想尝试 4-6 个，因为他们的调度程序是超监控的并且已经很忙）。
另外，我不确定您是否可以依靠 aws 为您提供可靠的 CPU 使用率，因为您获得的百分比是一个模糊百分比。
First off, you probably don't want instances at 45-60% cpu. In that case, if you get a traffic spike, all of your instances will choke.
Next, 14 Unicorn instances seems large. Unicorn does not use threading. Rather, each process runs with a single thread. Unicorn's master process will only select a thread if it is able to handle it. Because of this, the number of cores isn't a metric you should use to measure performance with Unicorn.
A more conservative setup may use 4 or so Unicorn processes per instance, responding to maybe 5-8 requests per second. Then, adjust the number of instances until your CPU use is around 35%. This will ensure stability under the stressful '20 requests per second scenario.'
Lastly, you can get more gritty stats and details by using God.
对于高 CPU 超大实例，每秒 20 个请求是非常低的。很可能是代码有问题。独角兽特有的问题似乎不太可能。如果您有疑问，您可以尝试不同的应用服务器并确认它仍然会发生。
在这种情况下，我会考虑的问题......
1 - 你是否在代码中做一些 CPU 密集型的事情——也许真的应该在数据库中。例如，如果您要带回一个大型记录集并在 ruby/rails 中循环遍历它以对其进行排序或执行一些其他操作，这将解释此级别的 CPU 瓶颈，而不是数据库中的瓶颈。在这种情况下，建议是修改查询以做更多事情并减轻负担。例如，如果您在控制器中对结果集进行排序，而不是通过 sql，则会导致这样的问题。
2 - 与 vanilla crud 应用程序相比，您是否在做任何不寻常的事情，例如访问共享资源，或者任何可能成为争用问题的事情？
3 - 您是否有任何可能烧毁 CPU 的循环，尤其是在争用资源的情况下？
4 - 尝试解开有问题的控制器逻辑的各个部分。例如，如果你修改你的代码只返回一个静态的 hello world 响应，它的扩展性如何？我敢打赌，独角兽会突然变得异常快。然后尝试重新添加部分代码，直到发现缓慢的根源。