我们在heroku上托管的Rails应用程序中提供了json API。我想在SQS队列上为每分钟大约800个请求的端点写一条消息。 每个请求会发送一条消息，其中包含一个非常小的正文（100字节字符串）
Queue和Heroku应用程序都位于爱尔兰。
我平均每次写入150毫秒（6.6 msg /秒）这是缓慢的方式：该端点的平均响应时间是100毫秒，仅通过写入SQS就可以将响应时间加倍，这是不可接受的
有几个消息来源表示，他们可以在同一地区从EC2实例到SQS写入高达50-80 msg /秒的时间。 Heroku实例托管在EC2上，那么可以解释这种差异呢？ 我们可以做些什么来提高写入吞吐量？
以下是我们的设置：
报告来源报告吞吐量增加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
答案 0 :(得分：1)
我假设您在heroku上测量自己的rails应用程序的总api响应时间。 很有可能它与几个dyno工人一起部署在独角兽上。每次Web请求进入时，它都由一个独角兽工作进程处理。当它正在与3D派对交谈时，它将阻止io通信，这意味着它将导致此工作进程等待，直到与3d方的通信完成。在等待时，独角兽工作者无法处理任何其他http请求。因此，大多数时候服务器被阻塞会导致吞吐量不佳。
您可以使用以下选项来解决此问题：
切换到多线程应用服务器（例如puma）
切换到公平的应用服务器（例如，精简版）并使用EventMachine.em_http_request向第三方执行非阻止io http请求。
使用多线程解决方案，您必须调整Threadpool号码。也许您希望将此功能提取到单独的应用程序中。因为在休眠模式下大部分时间都有一个大的Threadpool for Threads是完全没问题的，因为它被io操作阻塞但对于执行大量cpu工作的Threads来说并不是那么好，因为它们会受到上下文切换的影响。
如果你想在第三方通话结束时也向客户端发送响应，那么使用Rails和瘦是有点棘手的。但似乎possible。这是一个async_sinatra的nobrainer。也可以使用一些发布订阅解决方案来进行异步响应。