我们在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。也可以使用一些发布订阅解决方案来进行异步响应。