从 Heroku 写入 Amazon SQS：性能不佳

Question

我们有一个由 Heroku 上托管的 Rails 应用程序提供的 json API。我想在一个端点的 SQS 队列上写一条消息，每分钟大约有 800 个请求。 每个请求都会发送一条消息，正文非常小（100 字节字符串）

Queue 和 Heroku 应用程序都位于爱尔兰。

平均每次写入时间为 150 毫秒（6.6 毫秒/秒），这太慢了：该端点的平均响应时间为 100 毫秒，仅通过写入 SQS 将响应时间加倍是不可接受的

多个消息来源指出，他们可以从 EC2 实例向同一区域的 SQS 写入高达 50-80 msg/秒的速度。 Heroku 实例托管在 EC2 上，那么如何解释这种差异呢？ 我们可以做些什么来提高写入吞吐量？

这是我们的设置：

• Ruby 2.1.2
• aws-sdk 1.34.1
• 位于欧盟地区的 Heroku 应用
• SQS 队列位于 eu-west-1
• 在 2x dynos 上运行的独角兽

报告写入吞吐量增加 10 倍的来源：

http://aws.amazon.com/fr/blogs/aws/scaling-with-amazon-sqs/ http://notes.variogr.am/post/67710296/replacing-amazon-sqs-with-something-faster-and-cheaper http://www.quora.com/How-fast-is-Amazon-SQS

Answer 1

我假设您正在测量您自己的 rails 应用程序在 heroku 上的总 api 响应时间。 很有可能它与几个 dyno 工作人员一起部署在独角兽上。每次 Web 请求进来时，都会由一个独角兽工作进程处理。当它与 3d 方交谈时，它将阻塞 io 通信，这意味着它将导致此工作进程等待，直到与 3d 方的通信完成。在等待期间，独角兽工作者无法处理任何其他 http 请求。因此，糟糕的吞吐量可能是由于您的服务器大部分时间都被阻塞了。

您将有以下选项来解决此问题：

• 切换到多线程应用服务器（例如 puma）

• 切换到事件应用服务器（例如瘦）并使用EventMachine.em_http_request 向第三方执行非阻塞 io http 请求。

使用多线程解决方案，您必须调整线程池编号。也许您希望将此功能提取到单独的应用程序中。因为大部分时间都处于睡眠模式的线程有一个大的线程池是完全可以的，因为它会被 io 操作阻塞，但对于做大量 cpu 工作的线程来说并不是很好，因为它们会受到上下文切换的影响。

使用 Rails 进行事件处理有点棘手，如果您还想在 3rd 方调用完成时向客户端发送响应，那么它会变得很简单。但似乎possible。与async_sinatra 相得益彰。也可以为异步响应使用一些发布订阅解决方案。